[Top][All Lists]

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

Re: [Gnu-arch-users] Using arch for offline development

From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Using arch for offline development
Date: Thu, 13 May 2004 19:00:33 +0900
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux)

>>>>> "wazow" == wazow  <address@hidden> writes:

    wazow> This worries me too, but it is indeed slightly more
    wazow> flexible than with CVS.  With CVS I am stuck to have either
    wazow> local or remote repository.

Not at all; it's easy enough to make a mirror with rsync.  The big
danger with CVS is that it's hard to turn a copy repository (eg, with
rsync) into a mirror, so in practice you would end up with two live
repositories unless you're very disciplined.  So far I've been

    wazow> I cannot push the hole repository out of the machine
    wazow> whenever being offline (bcs this is a huge tarball with the
    wazow> entire cvs tree),

rsync fixes this at the cost of some CPU cycles.  I have colleagues at
XEmacs who rsync the 750MB XEmacs repository to a local mirror every
session.  I admin they've got broadband connections, but they hardly
have time to get coffee unless is very heavily loaded,
and all that time is used figuring out which files to sync---the
actual transfer is rarely more than a few 100KB.

    wazow> This mirror swapping with tla

I take back what I said about "dangerous"; I missed the fact that a
sync was being done _each_ time.  However, do be _very_ careful with
the script; make sure that even if the lights go out in the middle,
you never end up in a state with both archives "live".  I think making
"rm =mirror" be the last thing in the script should be sufficient.

    wazow> I start to think that [branching] would be cleaner, more
    wazow> tla-spirit and more flexible in the end. But what should
    wazow> this script use?

You could use

for i in `tla whats-missing -f address@hidden/bashrc--laptop---0`; do
  tla replay --exact $i \
    && tla commit -L "merged $i from bashrc--laptop--0"

in a workspace for address@hidden/bashrc--laptop-backup--0.
(See below for a sketch of the archive structure I'm assuming here.)

However, there is _zero_ reason with tla to have a single archive;
some people recommend archive-per-project, and there's no technical
reason not to!  Having a r/w archive for server versions of your
config files and a mirror archive for the laptop imposes little extra
burden on you.

So suppose we're talking about your .bashrc.  Then you might have
_three_ archives: laptop (on the laptop), laptop (on the server for
backup), and server (on the server).  Then on your laptop "tla
archives" would tell you


and on server


"tla abrowse -A laptop bashrc" would tell you

            [list of revisions]

"tla abrowse -A server bashrc" would tell you

            [list of revisions]

and bashrc--server--0--base-0 would be a continuation of
bashrc--laptop--0--base0.  (Or vice-versa.)  I think the only tricky
part is to make sure you cache the base-0 revision of the continuation
branch, although that may not be necessary.

Note that I have the mirror on server set up as a pushme-pullyou; you
can do the mirroring from either side.  If you'll always be doing it
from the laptop (respectively, server), you can omit -SOURCE
(respectively, -MIRROR) on the other.

This way, on server you always have access to the latest mirror of the

But on the laptop, you don't need to keep a mirror of server.  You can
just pull patches from address@hidden/bashrc--server--0 as

If you want to keep the patches pulled from the server separate in
your laptop branch, you might want to use a trivial script

tla replay --exact address@hidden/bashrc--server--0--$1 \
  && tla commit -L "merged $1 from bashrc--server--0"

Of course you have to take some care that parts of the server .bashrc
and the laptop .bashrc that are shared are kept in similar order, and
you don't mix non-shared "junk" in or you'll get gratuitous
conflicts.  I'll bet this only matters when you first set up, though.

Institute of Policy and Planning Sciences
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

reply via email to

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