Peter Davis <peter@pdavis.cx> writes:
> 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.
One thing to keep in mind is that whether one creates microbranches or
not, etc. is sort of a client issue. The server can store them
efficiently; the protocol lets you create them efficiently; what
features you provide with those facilities is up to the client.
One of the (unstated?) goals in Subversion was to keep the server's
semantics very simple, and push as much as possible into the clients.
It's much easier to experiment with new features on the client side:
- client-side bugs alone can't compromise the history on the server,
since there are no protocol requests that modify history (that's
still true, right?), and
- unlike the server, clients don't have to be shared by all the
developers on a project: one person can try out his own stuff
without inconveniencing everyone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 06:34:24 2002