[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Combining tagging and committing in a single version
From: |
John Goerzen |
Subject: |
[Gnu-arch-users] Combining tagging and committing in a single version |
Date: |
Thu, 04 Sep 2003 09:19:25 -0500 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) |
Hello,
The tla tutorial advises that arch is not set up to handle tagging and
committing in a single version very well. Here is a scenario where I
might be missing the proper way to handle things.
1. I have a branch in my archive tracking the primary Linux kernel sources,
for, say, 2.4.
2. I also have a branch tracking people's patches -- say the Alan Cox
tree.
Now, Alan Cox maintains a diff to the canonical sources, and each of
his new releases is just a new diff. Easy enough to integrate into
arch -- I'd tag, say, 2.4.10 into the ac branch and then start
applying diffs.
Now what happens when Linus releases 2.4.11? Well, I update the linus
branch and commit the new version. But I can't just merge this over
into the ac branch -- it will almost certainly contain changes that
conflict with it, and Alan may even undo some changes with his next
version. I'd really like to tag it over -- representing that the ac
branch for 2.4.10 is dead ans we're starting over -- and then commit
alan's changes after that. But I gather this won't work well.
Any ideas on how I would accomplish this nicely?
Another permutation of the same problem:
Sometimes there are pre-releases of kernel versions. I keep all the
releases in a single branch, and I'd like to keep all the
pre-releases in another. That way, I don't accidentally get a
pre-release when I check out the most recent revision.
Again, I could do the first prerelease fine. But a few kernel
versions down the road, how do I manage keeping the prerelease tree
up-to-date?
-- John
- [Gnu-arch-users] Combining tagging and committing in a single version,
John Goerzen <=