[Gnu-arch-users] Re: Some "How Do I" questions

[Miles Bader]

Colin Walters <address@hidden> writes:
> Wow, there's some cool stuff in there!

Thank you kindly... :-)

It's a cool thing about arch that it makes it sooo easy to export ones
changes (in a usable form) that it really does promote sharing.  Before
I'd never put anything in a publicly available place unless it was a
pretty polished finished product, but now, hell, why not?  Other people
are obviously doing the same thing, and it sometimes feels like you can
look into everybody's head (not always pretty, but hey).

Gee, I never really thought about it very much (I was always focused on
the technical side of things), but in this sense arch seems like an
incredible way to further the sort of sharing and community spirit that
free software is supposed to be about, but sometimes falls short of.
[Sourceforge and the like is nice and all, but man it's so heavyweight
that I'm amazed anyone bothers to use it.]

Tom, you sneaky bastard...

> I am looking at tla-cvs-sync now.  It looks pretty interesting.
> Just one minor thing I noticed; tla-cvs-sync needs to use mktemp or it
> is insecure on multiuser systems.  This is fixed in:

> Now...I'm not sure I understand how it works.  Does it expect the cvs
> directory to be based from the same branch as your main development
> branch?

I'm not sure what you mean -- it doesn't really `expect' anything, it
just gateways changes back and forth between whatever arch branch is the
default in the project tree being used for syncing, and whatever CVS
thinks is current (i.e., usually HEAD, but possibly a sticky tag).

It _does_ require that a dedicated _project tree_ be used for the
CVS-syncing; you should't be doing development in the same project tree
(otherwise the CVS syncing process will end up committing your changes
into random changesets as they flow back and forth between CVS and
arch).

> What I have is a totally separate --cvs branch, and a --mainline
> branch where I do all my work.  Then I just star-merge between them.

You could do that, though I see no particular necessity to keep two
separate branches.  It's the same as any branching decision in arch, I
think; if you're doing something you don't want automatically propagated
to CVS, you'd better not do it in the branch which is getting synced
with CVS.

Personally I usally commit obvious bugfixes and the like directly to
the `emacs--cvs-trunk' branch, which is what gets gatewayed; more
speculative stuff is done on its own branch.

In a sense, since CVS is still (thinking positively here :-) the main
repository for the emacs sources, I consider emacs--cvs-trunk the
`mainline' arch branch too, and think of the actual gatewaying as just
an implementation detail.

> So to do arch->CVS, I do
>  cd /path/to/rhythmbox-CVS && tla star-merge rhythmbox--mainline--1.0
> tla commit -L 'merge from mainline'
> # copy first part of output from `tla changelog` into the ChangeLog file
> cvs commit -m 'output from tla changelog goes here'
> tla commit -L 'update ChangeLog'

The arch->cvs part is basically the same; the differences are that my script:

 (1) Doesn't do any kind of merging from another arch branch.

 (2) It commits `pending' changesets individually to CVS, which I like
     because it preserves the changeset boundaries (as best can be done)
     even in CVS, and results in much more concise and useful log messages.

     [For the same reason, I don't like using star-merge for moving
     changesets from auxiliary branches to the `main' branch (by which I
     here mean the branch being CVS-synced, but it also probably
     applies to your `mainline' branch) -- when I do `tla abrowse -s'
     on the main branch, I'd really like to see exactly what happened,
     not just `Merge from FOO; Merge from FOO; Merge from FOO'.

     For merging _from_ a main branch to an auxiliary branch, OTOH, I
     just use star-merge; in this case it seems the right thing since I
     generally don't care what the changes from the main branch are,
     just that my auxiliary branch is up-to-date with them.]

 (3) Will automatically do any necessary cvs adds / removes.

 (4) Does a `cvs -q update' first, to lessen the possibility of the cvs
     commit failing (there's always a chance that the cvs commit will
     fail even then, but the script is designed to have a fairly simple
     `if something funny happens, fix any conflicts and reinvoke' usage).
 
 (5) _Doesn't_ attempt to do any automatic ChangeLog updating.  This is
     as much a cultural issue as anything, and since I wrote my script
     for emacs, that means traditional ChangeLogs (arch auto changelogs
     seem convenient to merge, but tend to be rather bloated, and I'm
     pretty sure RMS would have a fit if anything like that showed up in
     the emacs ChangeLogs).

     Of course one result is that ChangeLog conflicts are the biggest
     pain with doing this gatewaying, so I hope to write an automatic
     ChangeLog de-conflicter soon (it shouldn't be so hard since in
     general it's OK just to re-order the entries a bit).

 (6) Explicitly does `cvs commit FILE...' to avoid problems with stray
     changes in the project tree (this shouldn't usually be a problem,
     but I once-upon-a-time actually did a build from that project tree,
     so lisp/subdirs.el is perennially out of date :-)

> cvs->arch is just a star-merge.

You can star-merge from CVS :-? 

I think the only magic thing my script does is taking care of adding
taglines for new files from CVS, and handling changes in
externally-tagged files.

Er, sorry for the length of this... hopefully there's some info there
somewhere.

-Miles
-- 
97% of everything is grunge