[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la
From: |
nobody |
Subject: |
[Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux) |
Date: |
Sat, 06 Sep 2003 09:33:39 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en_US; rv:1.4b) Gecko/20030607 Mozilla Firebird/0.6 |
=================== BUG #5101: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5101&group_id=4899
Changes by: Damien Elmes <address@hidden>
Date: Sat 09/06/2003 at 13:33 (GMT)
------------------ Additional Follow-up Comments ----------------------------
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
:-)
=================== BUG #5101: FULL BUG SNAPSHOT ===================
Submitted by: tjl Project: GNU arch -- a revision control
system
Submitted on: Sat 09/06/2003 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: Sat 09/06/2003 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/2003 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/2003 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/
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/06
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/06
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/06
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux),
nobody <=
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/06
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/06
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/06
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/07
- [Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux), nobody, 2003/09/07