If part of the approve process consists of compiling and testing the
result of committing the txn, which it would in any sane
environment. You also need a way to update or switch a working copy
to a particular txn instead of a revision.
With the ability to modify a dangling txn by say adding revprops like
local:reviewed local:builds local:passes-tests, as the change goes
though the different stages of approval, you could simply check for
each of those before doing the actual commit in a pre-commit hook.
Finally if a txn can't merge for some reason, the user needs a way to
either update the old txn, or better yet leave the old one around for
reference and make a new txn from the wc of the old txn merged to
whatever place the txn is supposed to be applied. The new txn will
be missing the appropriate properties and will therefore need to go
though the review process again.
Michael
On Aug 23, 2005, at 1:36 AM, Chia-liang Kao wrote:
> On Mon, Aug 22, 2005 at 07:46:05PM -0500, kfogel@collab.net wrote:
>
>> Chia-liang Kao <clkao@clkao.org> writes:
>>
>>>> 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.
>>>
>>
>> Sorry, I'm not sure I understand.
>>
>> If commits come in later, but are non-conflicting with the dangling
>> txn, then the dangling txn can still be committed at any time. Why
>> would it be rendered in applicable?
>>
>
> It can commit if it's node-level non-conflicting. But I was talking
> about textually non-conflicting.
>
> Cheers,
> CLK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 23 17:34:33 2005