[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
delta).
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....
-Miles
--
Is it true that nothing can be known? If so how do we know this? -Woody Allen