[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merging and switching

From: Scott Lenser <slenser_at_gs104.sp.cs.cmu.edu>
Date: 2002-01-25 00:05:44 CET

> Given how rarely merges occur, is it worth jumping through hoops
> to reconstruct the fulltexts? Maybe it's just simpler to have
> the client grab the fulltexts directly. What do people think?
>

I don't think merges are all that rare of an event, or at least won't be
after not having to jump through the hoops that CVS makes you go through.

Consider a project consisting of several modules each with a team of people
working on the module. The teams all work on branches so that they can check
in code that is still buggy and get help from the other members of the module
team. The modules are tightly interrelated such that the API between modules
changes frequently. Then each module team needs to frequently merge changes
from the other modules in when they need new features and they may not be able
to simply commit a new version to the trunk if they are in the middle of
changes. I've seen development that worked something like this done to produce
VLSI CAD software for automated layout (the different parts of the problem
interact heavily but can be factored into modules enough to be useful).
Since CVS was being used, the way this was done at the time was through people
manually copying changes from working copy to working copy to share within a
team and checking in working stuff to the trunk. Branches would have provided
a much cleaner model and merges would have been common.

Just my 2 cents.

- Scott Lenser

PS: Thanks for producing a replacement for the heinousness of CVS! I look
forward to using it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:59 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.