[Top][All Lists]

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

RE: CVS - setup reserved checkout

From: Thornley, David
Subject: RE: CVS - setup reserved checkout
Date: Fri, 12 Oct 2001 15:45:15 -0500

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Friday, October 12, 2001 1:34 PM
> To: address@hidden; address@hidden
> Subject: RE: CVS - setup reserved checkout
> One would hope that one's shop is not using the same branch for both
> maintenance and new features.  That kind of thing is best done on
> separate branches (where the two schedules don't interfere with each
> other).  The bug fix is later merged into the new development when
> it's appropriate to do so.
The last job I had not involving the use of CVS was with SCCS,
and we didn't have branches.  This did make shipping bug-fixed
stuff to customers interesting.

Now assume the conditions where I'm working now, where the
new features go on the main trunk and the bugfixes will be
applied to a release branch, or maybe a patch subbranch.  These
need to be merged eventually, and I'd rather get them merged
now before the developer forgets about them.

> Under those conditions, almost any version control tool provides the
> necessary merge tool.  And locks don't matter because there's no
> concurrent development on the same branch.
Any version control tool with branches.  Of course, anything going in
on the release branch probably should go into the development
branch, and we're back to merging.  The question, I suppose, is
whether the merge will be done semi-automatically and promptly, so
that the developer fixing the bug will watch it happen and have the
problem fresh in his or her mind, or if it's going to be done manually
and possibly at a later time, when the developer doesn't quite remember
all the details, or not at all, and the developer finds a note three
years later stuffed into documentation for an old version of the
compiler about merging the change.

I know which I prefer, but others seem to prefer cases 2 or 3.

> 'Course, it's a different story if multiple developers are adding
> their own bug fixes or features on either branch...
Yup.  Any time more than one developer is working on things at the
same time, there's a need for merging.

It is possible to design a locking protocol that obviates the need
for merges or wasted work.  When a developer has a project, he or she
grabs all needed locks.  If that developer cannot grab all of them,
he or she releases the grabbed ones (to avoid deadlock, except in the
case of race conditions.  This can be avoided by giving each developer
a different time of day to grab locks).  If the developer has all locks
necessary for a task, he or she works on that task.  If the developer
does not have all locks necessary for any assigned task, that developer
surfs the web or plays bocce ball or something.

Personally, I'm not convinced that this is better than having to merge.

reply via email to

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