Peter Davis peter-at-pdavis.cx |Subversion list| wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Okay, I think I understand. Instead of simply having the commit fail and then
>running "svn update" (or "svn merge") and resolving the conflicts in your
>working copy, you want it to create a special branch so that the commit still
>succeeds, but isn't actually merged into the HEAD tree. That's an
>interesting concept.
>
>Since it is very easy and efficient to create your own branch in Subversion,
>you should be able to achieve the same goals, even if Subversion won't
>automatically create the branches for you. Personally, I'd even prefer that
>I have to make the branches myself, just because I never believe in overly
>"smart" tools. I can see how microbranches would be nice coming from CVS
>where it is difficult and time- and resource consuming to create branches
>manually.
>
2 Points here,
1. The Commit/Update process.
I think a commit should still fail if there's outstanding updates.
You then have a choice
a. commit to a branch and continue working, (probably imediately
doing an update on the trunk)
b. update from trunk, then comit.
2. Branching
At present, I don't think you can make a branch and commit to it, if
your sandbox is on
the trunk and the sandbox contains modifications.
I haven't tested that though.
>
>One question: 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 think what you're moving towards is something like a vendor-trunk
relationship here (something I don't fully understand)
>
>I'd hope this wouldn't be an absolute requirement for adoption by GCC or any
>other project. It would be a nifty feature, but it just seems like mostly
>sugar to me, especially given that one of the other requirements is that
>manual branches are quick and easy (and they are with Subversion).
>
So long as subversion provides the infrastucture, users can script to
create their desired
behaviour.
Apologies to Peter, for sending a mangled version of this mail to his inbox.
-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 13:05:23 2002