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

Re: gcc source management requirements

From: Robert North <aqh4uyrs3e02_at_sneakemail.com>
Date: 2002-12-10 20:53:57 CET

Peter Davis peter-at-pdavis.cx |Subversion list| wrote:

>Hash: SHA1
>On Tuesday 10 December 2002 04:04, Robert North wrote:
>>>what happens when you've finished merging the various changes in
>>>your microbranch, but someone else has made changes to the HEAD tree and
>>>the microbranch itself becomes out of date? When you commit it, do you
>>>get a micro-microbranch?
>>My assumption would be that best practice says: work on the trunk, if
>>possible. So, normally you'd only have the contents of a single commit on
>>your branch, followed by an update fron the trunk, some conflict
>>resoloution, and a commit to the trunk.
>I still see a problem there. Doing the conflict resolution in the branch
>takes time, during which someone else could have made another commit to the
>trunk. Once that happens, the branch would be out of date, and when
>committing the merged changes from the branch to trunk, it'd have to create a
>new branch to resolve the new conflicts.
If there are further conficts, then it's just as much a pain, as if
there were no "microbranches".

Have a look at <http://gcc.gnu.org/ml/gcc/2002-12/msg00487.html>
(As suggested by Zack elsehere in this thead) which explains far better
that I can, how this idea may work and deals precisely with the issue
you raise about
multiple commits.

For my needs, most of the infrastucture is already available. It's just
a case of stringing together a bunch of svn commands.

For gcc, I think they would require a more shrinkwrapped system.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 20:54:40 2002

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