[crossfire] crossfire source code control systems

[Alex Schultz]

Raphaël Quinet wrote:
> As a GIMP developer, I have been using
> CVS branches extensively: we always maintain HEAD together with at
> least one stable branche, while several experimental features are
> developed in their own branches, such as the recent Google Summer of
> Code projects.  We also perform a lot of merges from the HEAD branch
> to the stable branch and sometimes from the stable or experimental
> branches to the HEAD branch, as you can see in the ChangeLog from the
> stable branch: http://developer.gimp.org/ChangeLog-2.2
>
> So regardless of how the different systems support branching and
> merging, I think that the support offered by CVS and SVN is good
> enough in practice, including for large projects.  So all systems
> would get 1 point there.
>   
Well, I'm curious how the workflow would work for doing things like
bugfixes that you want merged so they are in both branches. In systems
with a distributed design like Mercurial and Bzr, the ideal workflow
(that I can see) would be to, make the bugfix in the stable branch, and
then pull from the stable branch to the head branch, and do a merge, and
fix the conflicts (which could be anywhere from so trivial the system
could deal with it on it's own, to making small changes to the fix, to
simply manually ignoring the bugfix's changes due to it no longer
applying). This keeps track of history the best, and actually would even
allow one to reconstruct the stable branch from the head branch, because
it would contain information about which revision they diverged at, and
not only how the bugfixes applied to the head branch, but also how they
applied to the revision where it branched from stable (not necessarily
the most useful of features, but it takes no effort to keep track of
oneself and makes the logs extremely accurate and complete). Now that
I've described the workflow one would probably use in distributed
systems, could you explain the workflow that is considered best to use
for CVS and SVN type systems for handling putting a bugfix in multiple
branches?

>> Another fact that was not taken into account it the fact sourceforge 
>> hosted revision control has the advantage of not having to duplicate 
>> user accounts. You can use the same accounts for revision control, bug 
>> tracking, releasing, web management, and project admins can manage all 
>> that using a single interface.
>>     
> Indeed, this is also an important point.  The integrated support for
> releases and downloads is not too critical because it only concerns a
> small subset of the developers (often a singleton) but having good
> links between the bug/patch/request tracker and the source code
> management system is a big plus for most developers.  So the systems
> supported by SourceForge get an extra point here.  I also like the way
> the GNOME and KDE projects have nice cross-references between the
> Bugzilla entries and the corresponding CVS or SVN changes: commit
> messages mention bug numbers that will be automatically linked to the
> bug reports in the viewcvs/viewsvn interfaces, and the comments
> closing the bug reports include the corresponding commit message.
>   
I'm not really sure that this integration is really so helpful. It's not
like sf.net does any cross referencing of it's own with that, and if we
were to do something along the lines of Mercurial over http, a policy of
using the same usernames as on sf.net could easily be used. The only
point of disadvantage I can see is from the admin point of view, where
to add a developer one would need to add both on sf.net and also to
wherever the repository is stored, however though I'm not a project
admin, I would imagine this would be a rather minor  bother to them.
>> The best solution to decide will probably be a vote amongst commiters as 
>> everyone probably has it's preferences.
>>     
> Yes, because although the matrix is nice, it does not and cannot
> accurately reflect the opinions of all developers: some reasons why
> some developers would prefer some systems over another may not have
> been stated yet in this discussion, or maybe they have been stated but
> not included in the matrix (for example, I suggested to rate the
> support for partial checkouts and for partial updates).
>   
Agreed, indeed the matrix can't accurately reflect the opinions of all
developers; when I made it I intended it to be simple a quick reference
for some of the features people were considering important in
discussion, and was aware that it was probably biased to some degree
though I did try to avoid bias as much as I could, of course avoiding
bias isn't a precise process.

Alex Schultz