[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
lucky....
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 cvs.xemacs.org 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
address@hidden
~/archives/laptop
address@hidden
sftp://server.gazeta.pl/var/arch/archives/laptop
and on server
address@hidden
/var/arch/archives/laptop
address@hidden
sftp://laptop.gazeta.pl/home/wazow/archives/laptop
address@hidden
/var/arch/archives/server
"tla abrowse -A laptop bashrc" would tell you
bashrc
bashrc--laptop
bashrc--laptop--0
bashrc--laptop--0--base-0
[list of revisions]
"tla abrowse -A server bashrc" would tell you
bashrc
bashrc--server
bashrc--server--0
bashrc--server--0--base-0
[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
laptop.
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
needed.
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 http://turnbull.sk.tsukuba.ac.jp
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.
- Re: [Gnu-arch-users] Using arch for offline development, (continued)
- Re: [Gnu-arch-users] Using arch for offline development, Charles Duffy, 2004/05/12
- Re: [Gnu-arch-users] Using arch for offline development, Matthieu Moy, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Andrzej Wasowski, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Tom Lord, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Karel Gardas, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Matthieu Moy, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Karel Gardas, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Stephen J. Turnbull, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Wazow, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Cameron Patrick, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development,
Stephen J. Turnbull <=
- Re: [Gnu-arch-users] Using arch for offline development, Jan Hudec, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Matthieu Moy, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, James Blackwell, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Matthieu Moy, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, James Blackwell, 2004/05/13
- Re: [Gnu-arch-users] Using arch for offline development, Tom Lord, 2004/05/14