discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: Subversion Migration


From: Wim Oudshoorn
Subject: Re: Proposal: Subversion Migration
Date: Wed, 12 Oct 2005 01:11:03 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin)

This discussion is quickly becoming off topic, so I think I will
drop out of it after this e-mail.

But basically my opinion is, stay with CVS for now and
go to another version control system when savannah supports it.

Also, I think that the developers who work with gnustep CVS the
most should decide, a group discussion will not accomplish much.

But to reply on a few of your points.

Helge Hess <helge.hess@opengroupware.org> writes:

>> 2 - Last time I looked, subversion did not keep track of merges,
>>     so trying to do multiple merges back and forth between
>>     branches is still a nightmare.
>
> Not sure what you mean / where the problem is, but merging works fine
> for us.

Well, I always had to think very hard when merging trees like:

            5--6         Branch B
           /  
       3--4--7--8        Branch A
      / 
 1---2--8--9--10         MAIN

           
Now suppose that have merged Branch A in B and change branch
A afterwards.  you have also merged Branch A at a later date in 
MAIN and now are going to merge Branch B in MAIN.  in the mean
time you keep developing on all branches and after a while
merge branch A again in B and also merge B back in MAIN.

With CVS this is somehow very error prone.  Especially because
CVS does not have a clue about the merge history so it does
not know what to merge.  Oh and btw this is not a purely
theoretical merge scheme for us.

>> 3 - Last time I looked, subversion was not great at operating
>>     in a disconnected distributed way.
>
> Subversion is just a better CVS, not a completely new approach to
> version control. So yes, but this is IMHO a good thing because you
> get a good set of features (/bugfixes) w/o a lot of work.
> Its basically like "upgrading to CVS 2.0" instead of enforcing a
> completely new approach.

Yes completely true. 
But I get the impression there is a lot of development going
on in version control land.  So subversion is close to CVS
and most other systems try to do significantly better than
the CVS/subversion model.  
So it might be better to wait until the dust settles and
pick a nice version control system when it is clear which 
ones are viable and fit the project best. 
Which could well be subversion.

Wim Oudshoorn.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]