Message-ID: <4197C7B3.6000908@panoramicfeedback.com>
Date: Sun, 14 Nov 2004 16:01:39 -0500
From: Aaron Bentley <abentley@panoramicfeedback.com>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
MIME-Version: 1.0
To: John Meinel <john@arbash-meinel.com>
Subject: Re: [Gnu-arch-users] Removing the last changeset(s) from the archive
References: <20041114111431.E15533@mofo.meme.com>	<4197AAA5.7080501@panoramicfeedback.com>	<20041114131902.Q15533@mofo.meme.com>	<1100459623.15201.46.camel@localhost>	<20041114134530.A23046@mofo.meme.com>
	<4197BF40.1010300@arbash-meinel.com>
In-Reply-To: <4197BF40.1010300@arbash-meinel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gnu-arch-users@gnu.org, Charles Duffy <cduffy@spamcop.net>,
        "Karl O. Pinc" <kop@meme.com>
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 1473
Lines: 45
John Meinel wrote:
> Karl O. Pinc wrote:

>> it's not exactly true that I want the trees in the archive to
>> work.  It's more like I want them to be mental checkpoints.
>> Done with this part, check. Done with that, check.  Goofing
>> up a commit violates this mental model.

> I think you've just described the difference between a dev tree, and a 
> stable tree.

While this is related to the idea of distrinct trees, I think it's 
actually something else.  It's a good idea to avoid mixing unrelated 
changes.  I think Tom calls it "clean changesets".  With clean 
changesets, you can replay the bugfix from devel into your stable tree, 
without merging the rest until it's ready.

This is one of the reasons I came up with "fai revert --hunks".  It lets 
me temporarily remove unrelated changes from a file, commit, "tla redo", 
  and continue.

> arch makes creating and maintaining concurrent branches very easy. Might 
> as well put that to good use.

Yeah, we certainly do.  At work, there's

1. current release
2. current build (based on 1, but with different build paramerters)
3. next release
4. my devel
5. other developer's devel.

When the other developer commits a bugfix, it gets merged like this:
5 -> 1 -> 2 and 5 -> 1 -> 3 -> 4

Aaron


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/