[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

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

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

reply via email to

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