gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] Managing a long-lived branch


From: Stefan Monnier
Subject: [Gnu-arch-users] Managing a long-lived branch
Date: 07 Apr 2004 19:07:28 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Let's say I have a long-lived branch which contains just a few small
changes compared to the main-line and that I need to keep uptodate w.r.t
the mainline.

It's something that's usually handled via something like CPP macros rather
than via a revision control system.  But CPP can't easily be used with all
files, and if I could use Arch for that it'd be great.

In this particular case, I'm trying to use Arch to manage my config files
(which are almost exactly the same on all my acounts, but not quite and for
some of those files, such as the .emacs file, I can use CPP-like
approaches, but for others I can't).

Using Arch in the most obvious way, it's pretty easy to do the merges, so
I'm fairly happy, but I have the following two problems:
- my branch will be full of merges.  There will also be some changes that
  don't come from merges (i.e. changes to the diff between the branch and
  mainline).  But those changes will be mixed with the rest and "lost in the
  noise".  Basically, I want to be able to separately look at the "changes
  from the mainline" and the "changes from the branch".
- I'd like to be able to commit "changes to the mainline" directly from
  the checked out tree of the branch.

To tell you the truth, I'm not sure exactly what I'd like to be able to do
and how it should work.

I tend to think of this problem in terms of "foo-branch" being the sum of
mainline and patch-foo where mainline and patch-foo are both revision
controlled objects.

For now, the way I deal with the above (for files where macro procesing is
not available), is that I let Arch manage a <file>.in and I then generate
<file> by running `make' (which will run <file>.in through a preprocessing
tool) everytime I do a `tla star-merge'.
[ For such a case as well, it would be handy if `tla' offered hooks run when
the local tree is modified. ]
The main problem with this approach is that every once in a while I forget
about <file>.in and edit <file> directly and then I lose changes, ...


        Stefan




reply via email to

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