You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "簡茂仰 (嘉宏)" <my...@esast.com> on 2005/08/21 08:31:14 UTC
Commit - Approve cycle ?
Dear all:
I saw this topic in mailing list archive before , I copied as below
> Is there a view to add some sort of approval facility into subversion
> where a commit goes into some queue and waits for approval ?
Answer by Ben Collins-Sussman
>>AFAIK, there's no concrete plan to add this feature to Subversion. On
>>the other hand, it would be very easy for a 3rd party to add this
>>"workflow" on top of Subversion. The repository has transactions
>>already; no reason for them to be committed immediately. A user can
>>commit his changes to a transaction, but then just leave the transaction
>>alive rather than committing it. Then a manager can come along and
>>peruse the transaction and do the final commit.
Ben mention it could be implement by committing changes to a transaction but
then just leave the transaction alive rather than committing it , But how to
achieve this feature ? Did it need to modify SVN source code or just
implement it in Hook script? And How to let the pending transaction commit
to repository? Any comment will be appreciated
MaoYang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by Andrew Thompson <an...@aktzero.com>.
Quoting Helge Jensen <he...@slog.dk>:
> Sorry to "barge in" on this discussion, I'm not entirely sure I
> understand the discussion, but it sounds to me like a search for a
> workflow that supports "approval" of commits.
>
> Couldn't this be solved with a simple way of working? without having
> commits "suspended".
>
> 1. copy from where you wish to commit to some other place.
> 2. while !done
> 2.1 edit
> 2.2 commit
> 3. start the approval procedure giving it the path where you copied
> to as input, and a description of what has changed.
>
> the approval procedure can:
>
> 1. merge current trunk (or whatever) with the changes
> 2. compile, test, ..., do manual edits and whatnot
> 3. commit or reject, giving feedback to requester of approval
>
> If the approval procedure is entirely automatic it should be no
> problem to automate the whole procedure.
A thread about approvals from a few months ago triggered a similar idea in my
head: http://svn.haxx.se/users/archive-2005-05/0536.shtml
Apparently no one else thought it was a useful idea, as there were no other
replies.
--
Andrew Thompson
http://aktzero.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by Helge Jensen <he...@slog.dk>.
Sorry to "barge in" on this discussion, I'm not entirely sure I
understand the discussion, but it sounds to me like a search for a
workflow that supports "approval" of commits.
Couldn't this be solved with a simple way of working? without having
commits "suspended".
1. copy from where you wish to commit to some other place.
2. while !done
2.1 edit
2.2 commit
3. start the approval procedure giving it the path where you copied to
as input, and a description of what has changed.
the approval procedure can:
1. merge current trunk (or whatever) with the changes
2. compile, test, ..., do manual edits and whatnot
3. commit or reject, giving feedback to requester of approval
If the approval procedure is entirely automatic it should be no problem
to automate the whole procedure.
--
Helge Jensen
mailto:helge.jensen@slog.dk
sip:helge.jensen@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by Michael Brouwer <mi...@tlaloc.net>.
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 <cl...@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
Re: Commit - Approve cycle ?
Posted by Chia-liang Kao <cl...@clkao.org>.
On Mon, Aug 22, 2005 at 07:46:05PM -0500, kfogel@collab.net wrote:
> Chia-liang Kao <cl...@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
Re: Commit - Approve cycle ?
Posted by kf...@collab.net.
Chia-liang Kao <cl...@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?
> 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.
That's exactly what I assume we would do.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by Chia-liang Kao <cl...@clkao.org>.
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
Re: Commit - Approve cycle ?
Posted by David James <ja...@gmail.com>.
On 22 Aug 2005 15:42:15 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> Chia-liang Kao <cl...@clkao.org> writes:
> 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.
Here's a quick hack that'll let you commit dangling transactions to a
local file:// repository.
Open up tools/examples/putfile.py, and comment out the lines which
commit the transaction. Then run the following commands:
svnadmin create repo
python putfile.py -m "dangling transaction" putfile.py repo
svnlook --transaction 0-1 diff repo
You will see a "diff" of your uncommitted transaction. If you later
decide to commit the transaction, you can also do this using the
Python bindings.
The patch to comment out the lines which commit the transaction is shown below:
Index: putfile.py
===================================================================
--- putfile.py (revision 15884)
+++ putfile.py (working copy)
@@ -44,8 +44,8 @@
handler, baton,
pool)
- newrev = repos.fs_commit_txn(repos_ptr, txn, pool)
- print "revision: ", newrev
+ #newrev = repos.fs_commit_txn(repos_ptr, txn, pool)
+ #print "revision: ", newrev
def usage():
print "USAGE: putfile.py [-m commitmsg] [-u username] file repos-path"
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Commit - Approve cycle ?
Posted by 簡茂仰 <my...@esast.com>.
Hi Karl:
>>but I think the larger challenge here is designing the interface and
workflow.
I suggest maybe workflow could be reserved implementing in Hook script and
it is flexible for integrating with third party workflow software , but SVN
need an interface in Hook script for enable commit as dangling or let the
tranaction pending, and third party workflow software could call SVN api to
continue or reject pending tranaction to do final commit
M.Y.
-----Original Message-----
From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net] On
Behalf Of kfogel@collab.net
Sent: Tuesday, August 23, 2005 4:42 AM
To: my@esast.com; Chia-liang Kao
Cc: dev@subversion.tigris.org
Subject: Re: Commit - Approve cycle ?
Chia-liang Kao <cl...@clkao.org> writes:
> Max Bowsher <maxb <at> ukf.net> writes:
>>> Ben mention it could be implement by committing changes to a transaction
>>> but
>>> then just leave the transaction alive rather than committing it
>>> But how to
>>> achieve this feature ? Did it need to modify SVN source code or just
>>> implement it in Hook script? And How to let the pending transaction
>>> commit to repository? Any comment will be appreciated
>>
>> 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.
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by kf...@collab.net.
Chia-liang Kao <cl...@clkao.org> writes:
> Max Bowsher <maxb <at> ukf.net> writes:
>>> Ben mention it could be implement by committing changes to a transaction
>>> but
>>> then just leave the transaction alive rather than committing it
>>> But how to
>>> achieve this feature ? Did it need to modify SVN source code or just
>>> implement it in Hook script? And How to let the pending transaction
>>> commit to repository? Any comment will be appreciated
>>
>> 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.
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by Chia-liang Kao <cl...@clkao.org>.
Max Bowsher <maxb <at> ukf.net> writes:
> > Ben mention it could be implement by committing changes to a transaction
> > but
> > then just leave the transaction alive rather than committing it , But how
> > to
> > achieve this feature ? Did it need to modify SVN source code or just
> > implement it in Hook script? And How to let the pending transaction commit
> > to repository? Any comment will be appreciated
>
> 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.
An alternative approach would be storing things in svk patch, which is like
an uncommitted branch that can be later merged. And it should be quite
easy to build UI on it to do click-to-test and click-to-apply.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Commit - Approve cycle ?
Posted by Max Bowsher <ma...@ukf.net>.
簡茂仰(嘉宏) wrote:
> Dear all:
> I saw this topic in mailing list archive before , I copied as below
>> Is there a view to add some sort of approval facility into subversion
>> where a commit goes into some queue and waits for approval ?
> Answer by Ben Collins-Sussman
>>> AFAIK, there's no concrete plan to add this feature to Subversion. On
>>> the other hand, it would be very easy for a 3rd party to add this
>>> "workflow" on top of Subversion. The repository has transactions
>>> already; no reason for them to be committed immediately. A user can
>>> commit his changes to a transaction, but then just leave the transaction
>>> alive rather than committing it. Then a manager can come along and
>>> peruse the transaction and do the final commit.
> Ben mention it could be implement by committing changes to a transaction
> but
> then just leave the transaction alive rather than committing it , But how
> to
> achieve this feature ? Did it need to modify SVN source code or just
> implement it in Hook script? And How to let the pending transaction commit
> to repository? Any comment will be appreciated
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.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org