[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 05.04.07 18:10:44, Matthew Woehlke wrote:
>> Hmm, there I disagree, branching is pretty fundamental, I would prefer 
>> to see that in the common interface. Wasn't the original post 
>> suggestions for the common interface, or did I mis-read somewhere?
> 
> No you did not mis-read. However I think copy and branch are not the
> same thing (except maybe in svn), i.e. I can copy filea.cpp to fileb.cpp
> (or rather do copy filea.cpp ../otherdir/fileb.cpp, for whatever
> reasons). While a branch really is a copy of a whole project for a
> specific matter (be it a feature branch or a maintenance branch). So if
> we want to support that via our VCS interface we'd have to have branch
> too.

I don't especially mind seeing a "copy" and "branch", although I suspect 
many VCS's implement them the same way. While there is certainly a 
semantic difference, a "branch" is really just a copy on a large scale. :-)

Somehow "integrate" got left off the list, that one is important.

> Also optional functions in an extension interface are possible too, just
> add an empty body to it in the interface (yes the class is not
> completely abstract anymore then).  Or use multiple interfaces:
> 
> IVersionControl for basic stuff
> IBranchVCS for branch/tag/...
> ICleanupVCS for cleanup/sync
> IWhatever for whatever ;)
> 
> Now that I think about it, this is the best way and actually exactly
> what the extension interfaces can help with. A vcs plugin must implement
> IVersionControl, and can additionally implement any of the others. It
> provides the information which interfaces it implements already.

Hmm... This covers all the advantages of my "standard actions" idea (one 
of which was common names and shared translations) in an elegant manner. 
I like it. :-) And since you like it, and Matt Rogers also likes it, I 
think we have a winner.

This would also allow something like kdelibs policy, we can "strongly 
encourage" people to write additional interfaces for their own VCS 
plugins and to look at what other VCS plugins offer before writing their 
own interface. Then when two or more want to share an interface, it is 
migrated up the tree.

-- 
Matthew
If you believe you received this e-mail in error, you are probably sadly 
mistaken, but if not, aren't you lucky?