bugGNU arch -- a revision control system - Bugs: bug #5101, Major use case: accept / reject...

 
 

bug #5101: Major use case: accept / reject patches (a la Linux)

Submitted by:  Tuomas J. Lukka <tjl>
Submitted on:  Sat 06 Sep 2003 12:57:04 PM UTC  
 
Category: tla documentationSeverity: 3 - Normal
Item Group: small feature ideaStatus: None
Privacy: PublicOpen/Closed: Closed
Release: 1.1pre5
Fixed Release: 
Merge Request?: None
Your Archive Name: 
Your Archive Location: 
Assigned to: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 06 Sep 2003 02:28:34 PM UTC, comment #6:

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.

Tuomas J. Lukka <tjl>
Sat 06 Sep 2003 02:08:43 PM UTC, comment #5:

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.

Damien Elmes <resolve>
Sat 06 Sep 2003 01:44:44 PM UTC, comment #4:

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.

Tuomas J. Lukka <tjl>
Sat 06 Sep 2003 01:33:39 PM UTC, comment #3:

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 pm@s--work-archive/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 pm@s--archive-location/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 developers@archive--location/name--branch--1.0--patch-2
tla replay --exact developers@archive--location/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 :-)

Damien Elmes <resolve>
Sat 06 Sep 2003 01:15:38 PM UTC, comment #2:

I would, but the problem is: I really don't know how to make it work cleanly!

That's why I'm asking ;^)

Tuomas J. Lukka <tjl>
Sat 06 Sep 2003 01:12:28 PM UTC, comment #1:

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.

Damien Elmes <resolve>
Sat 06 Sep 2003 12:57:04 PM UTC, 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)

Tuomas J. Lukka <tjl>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follows 1 latest change.

Date Changed By Updated Field Previous Value => Replaced By
Tue 13 Jan 2004 11:31:31 PM UTCtomlordOpen/ClosedOpen=>Closed

Back to the top


Powered by Savane 3.1-cleanup1