[Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux)

[nobody]

=================== BUG #5101: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5101&group_id=4899

Changes by: Jason McCarty <address@hidden>
Date: Sun 09/07/03 at 18:42 (GMT)

------------------ Additional Follow-up Comments ----------------------------
I think the cleanest way to do what you want might be for each developer to 
have a separate single branch for patch submission, using tags instead of 
merging.



So you might work on one or more feature branches, and when you're ready to 
submit it, you tag your submission branch from a recent mainline, and 
replay/star-merge the changes you want to export on it, as clean changesets. If 
the PM wants you to change something, you just manipulate the submission branch 
until it suits him, and when ready, he updates/replays/star-merges from you.



You could organize this two ways:

  Have each submission revision implement one feature, so the PM can 
cherry-pick them. If he wanted you to change one of them, you'd have to re-tag 
from mainline, and commit each feature again.

  Submit only one feature at a time, contained in multiple patches. When the PM 
wanted you to change something, you'd just commit a revision with those 
changes. Then when the PM updates, he ends up with the desired changes: even 
though the undesired code is in one revision, it gets fixed by a later revision.



This way you don't muck up your working branch(es), while still accomodating 
the PM and making it fairly easy on both of you. Afterwards, you can update 
your working tree to mainline with whichever way is easiest, rather than 
cleanest for the PM.



=================== BUG #5101: FULL BUG SNAPSHOT ===================


Submitted by: tjl                     Project: GNU arch -- a revision control 
system
Submitted on: Sat 09/06/03 at 12:57
Category:  tla documentation          Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  None                     
Status:  Open                         Release:  1.1pre5                     
Fixed Release:                        Merge Request?:  None                 
Your Archive Name:                    Your Archive Location:                
Assigned to:  None                    

Summary:  Major use case: accept / reject patches (a la Linux)

Original Submission:  One really important use case that's not documented well:



One project manager, several coders. Coders submit changes to project manager, 
project manager may 

1) accept as is

2) reject completely

3) accept, given some further work on the patch ("document this function, do 
this thing in a different way ...")



Now, the problem is how to make this work cleanly in arch.



The problem is mostly related to the handling of the coders' trees and patch 
logs. Somewhat similar to "cherrypicking changes" but in a different way.



The coders want to 1) keep their own changes they're working on , 2) stay up to 
date with project manager's version



Documenting how to make this model work in the docs would be *REAL* nice. ;)



(background: I lead the fenfire (fenfire.org) project and we're planning to 
move to using tla for versioning and would like to use the model I outlined 
above)

Follow-up Comments
*******************

-------------------------------------------------------
Date: Sun 09/07/03 at 18:42         By: jmccarty
I think the cleanest way to do what you want might be for each developer to 
have a separate single branch for patch submission, using tags instead of 
merging.



So you might work on one or more feature branches, and when you're ready to 
submit it, you tag your submission branch from a recent mainline, and 
replay/star-merge the changes you want to export on it, as clean changesets. If 
the PM wants you to change something, you just manipulate the submission branch 
until it suits him, and when ready, he updates/replays/star-merges from you.



You could organize this two ways:

  Have each submission revision implement one feature, so the PM can 
cherry-pick them. If he wanted you to change one of them, you'd have to re-tag 
from mainline, and commit each feature again.

  Submit only one feature at a time, contained in multiple patches. When the PM 
wanted you to change something, you'd just commit a revision with those 
changes. Then when the PM updates, he ends up with the desired changes: even 
though the undesired code is in one revision, it gets fixed by a later revision.



This way you don't muck up your working branch(es), while still accomodating 
the PM and making it fairly easy on both of you. Afterwards, you can update 
your working tree to mainline with whichever way is easiest, rather than 
cleanest for the PM.

-------------------------------------------------------
Date: Sat 09/06/03 at 14:28         By: tjl
Thanks, this is going a LONG way towards helping me understand. Once my 
immediate deadline rush (18th sep) is over, I'll try to submit a patch into 
this bug.



So the basic feeling I'm getting is that making branches is the tool to use, 
and something that can be done with far less thought than in, e.g., cvs. Of 
course, it'll still be nasty for the developer to keep track of all the new 
branches he is creating but it's still possible.



I still don't quite see how the developer will, after e.g. splitting the patch, 
or doing the branch off patch-3, get his own tree in order easily.



Re: making the same patch, I'm more worried about the developer merging his 
tree after one of his patches was rejected that way, the change coming from 
another patch.

Is there any better way than manually seeing replaying his other patches to a 
clean branch? Hmm, but at least that'll work.





-------------------------------------------------------
Date: Sat 09/06/03 at 14:08         By: resolve
on tracking patches - there's a mythical "patch queue/manager" thing which I 
believe should go some ways to helping to track requested changes. Nothing's 
been written yet, as far as I know.



On the issue of grabbing patch-2,-3 and 6, when there's a dependency on 4 - 
this has been discussed on the mailing list before. DARCS attempts to track 
patch dependencies, for instance. The conclusion on the list is that this is 
not always a good thing, and there are areas where it can get in the way.



Basically there is still an onus on the developer to create clean changesets. 
If they have made some changes which will influence patch-6, then they are 
better off tagging off patch-3 (ie, creating yet another branch), fixing it as 
per the PM's request, and then giving the PM that branch instead. There's 
obviously room to make this a more seemless process, but it's still pretty easy 
as is.



Splitting things in half - again, creating another branch is I presume the best 
way. I don't have experience with that.



Reverting a change: just use tla replay --reverse --exact 
name--branch--1.0--badpatch. If the PM is cherrypicking, the PM will have never 
got the patch and won't need to revert - so it's just a matter of the developer 
needing to revert if it will affect their subsequent changes.



If two developers make the same patch - then there's conflicts. If it was in a 
separate patch (which it should be), the PM can avoid grabbing one of them. If 
the similarity is burried within a bigger changeset - well, it shouldn't be. 
tla undo/redo can be very helpful in making clean changesets without getting in 
the way.

-------------------------------------------------------
Date: Sat 09/06/03 at 13:44         By: tjl
Yes, that's the simple case. This part is what I'm pretty clear about. 



However, it gets complicated when the PM says



"I'll accept if you first javadoc function X"



(the solution to this is relatively easy - the developer sends PM another 
message: "merge patch-2, patch-3 and patch-6 from my archive). That's ok. 
UNLESS my patch-4 rearranges the file so that patch-6 doesn't work without it.

How does the developer 1) make a clean patch, 2) recover his tree cleanly.

Or: if the PM says



"I'll accept the bug fixes to foo but not bar before you do X" - needs 
splitting changeset to half, how does the developer handle this cleanly?



"I don't like this change at all - it complicates file X" (i.e. straight 
rejection) - how does the developer clean his tree to follow PM's tree without 
getting his other changes clobbered (i.e. getting rid of that patch in his own 
tree as well).



"I've committed my own version of the changes you requested" (or: "developer X 
already sent similar patch to me") - without committing the patch log. How does 
the developer make his other work merge properly around this.



-------------------------------------------------------
Date: Sat 09/06/03 at 13:33         By: resolve
Whirlwind tour:



* project manager creates an archive (register-archive, archive-setup or import 
--setup) and puts the source in it. this archive is considered the "defacto" 
archive - other people will be pulling changes from it (though they can pull 
changes from fellow developers too, that doesn't happen as often)



* if the PM does not have the archive in a public location, they can create a 
mirror with make-archive.



* developers register the PM's public archive (register-archive). they can pull 
bits they need to build directly (get). for bits they want to modify, they want 
to create their own branch instead



* to create their own branch, they do something like:



tla archive-setup name--branch--1.0



Assume that the PM called their branch



defacto--branch--1.0



(it can be named the same if you want, though)



The developer then tags their branch as a continuation of the PM's - in other 
words, they say "copy the PM's branch into this one":



tla tag address@hidden/defacto--branch--1.0 name--branch--1.0



At this point, if you were to get name--branch--1.0, you'd have the same result 
as getting defacto-- instead. But note that it tags the current latest version 
of defacto - so if future changes are made to defacto, they are not reflected 
in name--.



* developer gets a working directory



tla get name--branch--1.0



* makes some local changes, commits:



tla commit -L "my local changes"



* wants to get the latest changes the pm has made



tla star-merge address@hidden/defacto--branch--1.0 .

tla commit -L "merge with PM"



(the changelog includes a list of the merges from the PM automatically)



* developer wants to push their changes to the PM. the developer makes sure 
their archive is in a public location (creating a public mirror if necessary). 
developer sends a changelog or a message saying "grab patches 2 and 3"



 - PM ensures the developer's public archive is registered (register-archive)

 - PM grabs the changes:



tla replay --exact address@hidden/name--branch--1.0--patch-2

tla replay --exact address@hidden/name--branch--1.0--patch-3



(this command line syntax is relevant to only the very latest tla - the arg 
format was changed recently).



 - PM reviews - they can use a separate tree for the review process, or "tla 
undo" to get rid of the replayed changes if they want.



 - PM commits



tla commit -L "merged with developer"



again, the changelog includes details of all the changes the developer made.



If you feel like tidying that up into a document, I'm sure it'd be appreciated 
:-)

-------------------------------------------------------
Date: Sat 09/06/03 at 13:15         By: tjl
I would, but the problem is: I really don't *know* how to make it work cleanly!



That's why I'm asking ;^)

-------------------------------------------------------
Date: Sat 09/06/03 at 13:12         By: resolve
For a real life example, look no further than arch - this is exactly how arch 
development proceeds.



I'm not sure a bug report will help much, though - it really just needs someone 
to "sit down and do it". I made some initial work towards some a quick primer 
for arch (http://repose.cx/ArchPrimer.html) but have been too busy with other 
things recently to polish it off and look at getting it integrated into the 
tutorial. If you're already familiar with arch, just bite the bullet and write 
it :-)



This model is probably a good selling point for arch, too. The tutorial could 
probably do with a rough overview of how it works (without the explicit 
commands to confuse the matter), in a section near the start entitled something 
like "Why arch?". Or maybe there's a section like that already, and I just 
missed it first time around.


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5101&group_id=4899

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/