Re: [Gnu-arch-users] Working out a branching scheme [was: tag --seal --fix]

[Tom Lord]

    > From: Juliusz Chroboczek <address@hidden>

    > TL> So, sealing is a kind of advisory lock and you can use it to model
    > TL> releases.

    > That appears to be what I'm looking for.  Thanks a lot.  (And thanks
    > to Dustin for the link.)

    > Before I switch to arch, I'm trying to work out the branching model to
    > use.  I'm thinking of the following.

    > All development happens on foo--devel--0.7.  When 0.7.0 is released,
    > it is tagged as foo--release--0.7.0.  Bug fixes to the 0.7 branch
    > continue on foo--devel--0.7, with later tags foo--release--0.7.1 and
    > so on.  There are never any commits on the foo--release branch.

    > When a new unstable branch is created, it is tagged as
    > foo--devel--0.8.  Development happens on this new branch, and bug
    > fixes to the stable branch can go to foo--devel--0.7.

    > I guess what I'm trying to achieve is something equivalent to cvs
    > symbolic tags, which I'm used to.  If you see better ways of doing
    > that, I'm all ears.

Nope -- that's exactly (but not exclusively) right.

You can use a "tags only" branch as a symbolic tag --- the variety of
tag that you explicitly move.   Unlike CVS, the history of the tag is
preserved.

One variation, if your releases include multiple projects, is to make
a top-level directory containing config files --- and use tags of that
top-level dir to mark your releases.

Some people will tell you (not incorrectly) that you can also blow off
tags entirely and use nothing but config files --- personally, I like
tags just to give releases a fixed name in the arch namespace.


    > Oh, by the way: there are two things that are easy with cvs that I
    > couldn't work out how to do with arch without checking out at least
    > one old version.  One is

    >   cvs diff -r FOO_0_7_0 -r FOO_0_7_1

    > which allows me to get a patch between two old versions.  

For that and other reasons you'll want to setup a revision library and
figure out how you want it configured (greedy?, sparse?).

The `tla delta' command can give you a changeset.   The changeset is
saved as output by default but, with --diffs, you'll just see a
display of its contents.


    > The other is
    > to generate a patch in which all file deletions and moves are made
    > explicit with suppressions and additions.  In short, I'm looking for
    > an efficient way to do:

    >   tla get foo--release--0.7.0 ,foo-0.7.0
    >   tla get foo--release--0.7.1 ,foo-0.7.1
    >   diff -urN -x '*/{arch}/*' ,foo-0.7.0 ,foo-0.7.1
    >   rm -rf ,foo-0.7.0 ,foo-0.7.1

    > (And of course the ability to do cvs export, but that's already in the
    > wiki.)


Strangely enough, we have only commands that produce output _close_ to
that but not exactly what you are looking for.

It would be an easy change to add to
src/tla/libarch/changeset-report.c to give a format along those lines
and propogate it to various commands as an option.   

It would obviously be a very good thing to do and I'll happilly accept
good patches along those lines.

-t