Peter Davis peter-at-pdavis.cx |Subversion list| wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>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.
Cheers
-Rob.
---------------------------------------------------------------------
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