[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Managing a long-lived branch

From: Miles Bader
Subject: [Gnu-arch-users] Re: Managing a long-lived branch
Date: 09 Apr 2004 15:24:47 +0900

Stefan Monnier <address@hidden> writes:
> Using Arch in the most obvious way, it's pretty easy to do the merges, so
> I'm fairly happy, but I have the following two problems:

What's the most obvious way, btw?

> - my branch will be full of merges.  There will also be some changes that
>   don't come from merges (i.e. changes to the diff between the branch and
>   mainline).  But those changes will be mixed with the rest and "lost in the
>   noise".  Basically, I want to be able to separately look at the "changes
>   from the mainline" and the "changes from the branch".

Hmmm, if your checkout is from the patched branch, and the patched
branch is a modification of the main branch, then of course

   tla changes --diffs my-configs--main--0

will do the latter (well, absent tree local changes -- but you can use

For the former case, you can use `tla delta' but it's slightly annoying
because you've got to supply the revision numbers yourself, e.g.:

   tla delta --diffs `tla logs -f my-configs--main--0 | tail -1`   \
                     `tla logs -f my-configs--patched--0 | tail -1` 

seems like it should do the job

[I've always wished that `tla delta' and other commands (like
apply-delta) would accept versions as arguments, as well as revisions,
and use the latest revision in the version -- but I'm never quite sure
if it should use the tree-local latest revision or the archive latest
revision ... though obviously in the above example you want the former.]

> - I'd like to be able to commit "changes to the mainline" directly from
>   the checked out tree of the branch.

Since commits must apply cleanly, it seems like you've got to do
something like:

   tla undo -o ,commit
   tla undo my-configs--main--0
   tla redo ,commit
   # assuming no problems
   tla commit -s'...' my-configs--main--0
   tla redo

If the first redo fails, it seems like it's gonna leave the tree in a
funny state -- which is desirable because it's what you need to fix
things, but might be a bit confusing if all of the above is embedded in
a single command.

What I personally do is just keep trees around for all `component'
versions, and after I've hacked on something in a `derived' version, I
decided which component version the change really belongs in, and then
just do:

   tla undo
   mv ,,undo-1 ../component
   cd ../component
   tla redo
   tla commit -s'...'

Not all that much shorter I guess, but it keeps things clear in my mind....

Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]