On Fri, 2002-12-13 at 22:03, Branko Èibej wrote:
> >basically a failed commit is an unfinished transaction, which violates
> >repository policy (e.g. not the branch's head was used as the base).
> >Now instead of forcing a transaction rollback now, if we allow the
> >client to keep the transaction open and do further work on it, we
> >suddenly do have "microbranches" for free.
> Oooh, someone else has thought of long-lived transactions. Welcome to
> the club. :-)
A note here:
With the current FS code, we could treat unfinished transactions as
microbranches. But if a transaction fails to automerge, no amount of
additional work on the transaction will make it commitable. You can't
currently change a transaction so that "this file here, which used to
have base revision 4, now has base revision 5, and these new contents."
(I have 90% certainty in the previous statements.)
Even with that limitation, you could:
* Leave the transaction around in the repository forever, so that the
data doesn't get lost.
* Merge the transaction's changes against a more current WC, producing
something commitable.
But that's actually not a bad discipline. If you do the merge *from*
the unfinished transaction instead of *to* it, then you never destroy
the information about what you previously wanted to commit.
Of course, these things would require noticeable changes to the layers
on top of the FS (libsvn_ra, libsvn_client, and the command-line client
itself).
Other things you can do with long-lived transactions (nothing people
haven't mentioned on this list before):
* Escrow potential commits for code review.
* Implement a client interface for wc-less manipulations of the
repository. Such an interface could allow a series of O(1) tree
manipulations to take place within a single transaction, without the
potentially large expense of representing the new state in a working
copy.
The one thing we don't want to do is implement intermediate commits
within long-lived transactions. That would cross the line from
"microbranches" to "real branches," and we already have a different way
of doing branches. (Plus, it would involve changing the filesystem
schema, whereas none of the previously mentioned functionality requires
any changes to the FS.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 23:36:46 2002