[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-12-14 23:35:57 CET

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

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