On Mon, Aug 22, 2005 at 03:42:15PM -0500, kfogel@collab.net wrote:
> >> It would require lots of new code.
> >> What exists so far is just the capability of the repository to store an
> >> uncommitted change. Very little of the logic to make use of that
> >> capability exists. In practice, just have developers commit to
> >> personal branches, and have the manager merge to trunk.
> >
> > Also you will have to update the uncommitted transaction with textual merges.
>
> I actually disagree that this would require lots of new code. Also,
> it does not require updating the uncommitted txn with merges -- that's
> a further enhancement, not a necessity for the basic feature.
That means any other non-conflicting commit actually got committed would
render the txn unapplicable, which you will naturely do a merge and
regenerate the txn. Since you have to do that, I think software should
probably do it for you.
> What Subversion needs is a small change, a way to commit such that the
> txn is left dangling. Then the bindings offer the rest of what's
> needed. Of course, new code would need to be written around
> Subversion, but I think the larger challenge here is designing the
> interface and workflow. The actual coding task is not so large.
Depending on which layer this is going to be. You can commit a txn from
fs layer of course, and now with 1.2.x you can even run commit_editor
with existing txn.
You also need the interface to somehow bring the changes in the pending
txn to the client side so it can actually be reviewed.
Actually what svk patch does, with a base root and serialised editor
calls, is exactly the same as using txn, running delta between its
base root and txn root. It's just already existing today, and hooked
with merge code already.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 23 01:25:34 2005