[crossfire] Crossfire Release Cycles/Methodology

[Mark Wedel]

Alex Schultz wrote:
>
>> - Should we switch to SVN?  Switching repositories at same time as switching
>>    what the head branch means would make the most sense.
>>   
> I agree that when switching what the head branch means makes the most
> sense, however I'm not sure that to SVN would be a great type of move to
> me. SVN from what I've seen does address some of CVS's weaknesses,
> however I have heard that the way it handles branching for example is
> ugly. Could someone with more experience with SVN comment on branching
> in SVN? Also, if we are willing/able to move off of sf.net for version
> control, it might be worth considering other version control options (I
> personally think that if we don't use either SVN or CVS, we should see
> if we can set up a read-only CVS or SVN mirror for people to download
> off of who don't have the other type of version control software.)

  I looked over the manual, and it is different for versions/branches.

  Within SVN, when doing a branch, or symbolic tag, you basically make a copy of 
the tree to a new location (there are svn commands for it).

  So under their scheme, you would have something like:
crossfire/branches/1.9
crossfire/branches/1.10
...
crossfire/trunk/... (Same as CVS head).

  There are also commands to do merges between a revisions in a branch and the head.

  Thus, suppose a bugfix is made between 500 and 501 in button.c in branch 1.10. 
  There is a svn command you can use which will pull that difference and try to 
apply that change to the trunk (or really, any other directory).

  All that looks pretty good.  The downside to all of this is that things like 
log/history can only show ancestors of the tree you are in.

  Thus, a svn log of the 1.10 branch/include/define.h will show the 1.9, and so 
on, back to where it broke off from the trunk.

  Doing that within the trunk will only show the revisions in the trunk - it, 
for lack of better term, has no knowledge of the branches, so can't show those.

  Thus, managing changes in branches can become harder, as it can be harder to 
find out all the info related to file.

  For example, suppose a 1.10.1 release is needed because of a critical bug. 
Developer goes and makes the branch, and fixes up the file in that branch and 
commits it.

  Suppose for whatever reason, they don't update the other trees (in a rush, 
going on vacation, whatever).  Unless you know to check out the 1.10.1 branch, 
you won't be able to see such a change has been made.

  In comparison, CVS makes this a little easier - a cvs log on foo/bar.c will 
show all info, including branches, for that file, so you can easily see 'ah, 
such and such change was made in 1.6.1.1'.

  I'm not sure how big a deal that really is.  It certainly looks like SVN has 
nicer abilities to merge changes.

  As far as going to something else, I think it would have to be vastly better - 
sourceforge provides a nice free environment - it keeps things very simple - it 
is associated with a group, not a single person.

  Something that is not free or associated with one person can become a problem. 
  Suppose there is some cool site that provides a nice source control package 
for a relatively nominal amount of money, and I'm willing to pay it.  That works 
great unless I'm hit by a meteorite, and which time, that could just disappear 
without anyone really knowing why (same points apply to services hosted on a 
persons private computer, etc - it sounds reasonable, but if something happened 
to that computer (house burns down), first priority for that person probably 
isn't getting that server set up again).

>> - Need some way to drive development - need some way to make sure items
>>    on TODO list for next release get done, and that developers just don't
>>    work on cool features they want that may not match TODO list
> Well, the best method of dealing with this I've seen, is with how many
> projects set things like "Blocking 2.0" in their bugzilla system. We
> might be able to use either categories or priority with the sf.net
> tracker, however that seems hackish to me and wouldn't be the clearest.
> That said, I think if we are to continue using the sf.net tracker, it
> would be best to use that for TODO goals, however I think it may be
> worth considering moving off of sf.net for bug tracking.

  I don't see any issue with the SF net tracker.

  The real problem is that if items alpha, beta, and gamma are on the list of 
things to do for the next release, and someone does epsilon, which isn't on the 
list, do you reject the changes saying 'hey, not on the list'?  We really can't 
do it, so what can happen is that alpha, beta, gamma might never get done but 
other features show up.

  OTOH, maybe that is a good indication that some features should be revisited - 
if no one is willing to work on what is considered some needed feature, maybe 
that feature isn't as needed as people think.