[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: Maintaining private changes with upstream tarball r
From: |
John Goerzen |
Subject: |
[Gnu-arch-users] Re: Maintaining private changes with upstream tarball releases? |
Date: |
Wed, 10 Sep 2003 04:50:57 -0500 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) |
Doran Moppert <address@hidden> writes:
> - create a project--release branch. project--release--2.0.8 will be a tag of
> project--main, and project--release--2.0.9 will be a continuation which
> merges in whichever enhancement-branches have been approved
I tend to use configs to checkpoint particular releases, but this
works too.
> Can you give a short synopsis on using tla_load_dirs for the first steps of
> this? I can't figure out which options I need ... :(
Sure. If you're bootstrapping the project from scratch, you'll need
to create a branch for development (via tla archive-setup or
make-version and friends.)
Then, I generally use tla import to load up an empty directory as the
first revision. Use tla tagging-method explicit followed by tla
commit to set up the tagging method to work for tla_load_dirs.
(The above are pretty standard tla biolerplate.)
Now, cd into your working copy (use tla get to check it out if
necessary.)
All you have to do is run:
tla_load_dirs /home/youruser/path/to/upstream
Where the path to upstream is the place you untarred it.
You just run the same command each time you have a new version to
load.
Under the hood, here's what's happening:
The first time you run it, tla_load_dirs will notice the changes from
the empty directory to the upstream set and issue bunches of tla adds.
(This is not actually a special case for tla_load_dirs) Subsequently,
it will issue tla add/tla delete commands to make sure your tla
repository stays in sync with upstream.
If a single import would introduce both adds and deletes to the
archive, tla_load_dirs presents you with a list of each, and offers to
let you match them up as renames. If you do this optional step,
tla_load_dirs will issue tla move commands, so that change history is
managed better. (This is the whole point of tags, and the main reason
I wrote tla_load_dirs) tla_load_dirs handles both directory and file
renames, and shows you directory candidates first, since renaming them
can save you a lot of hassle of renaming individual files.
After doing all this, tla_load_dirs normally generates a log message
and commits the changes. You can use the -l, -L, or -s to add custom
text to the log message (they work very similar to the flags of the
same name to tla commit). You can also use -n to tell tla_load_dirs
do do everything *except* the actual commit.
The only other options refer to verbose status output (use -v if you
want to see what's going on under the hood) and help information
(tla_load_dirs --help shows you a summary of all options).
tla_load_dirs is written to be easily scriptable and is careful to
return a successful exit status only if it really was 100% successful.
(As part of that, it takes note of exit status of subcommands, too.)
Hope this helps!
-- John