Re: [Gnu-arch-users] reality check and architecture RFC

[John A Meinel]

Stuart Jansen wrote:

>First, let me start by thanking the developers for arch. After CVS and
>Subversion, it has been a wonderful experience.
>
>Now for my question. I'm working on three closely related projects.
>Periodically, the three parts are combined to create releases. I would
>like to archive this exact combination in case we need to return to it
>at some point. I'm thinking about the best way to do so.
>
>
Use a Config file.
Specifically, it is just a file that contains:

./path/to/project   address@hidden/project--branch--version--patch-34
./path/to/next       address@hidden/project2--branch--version--patch-35

For comparison, you can look at the baz source tree, where it has
"dists--bazaar--1.5" package, inside of which is a releases directory,
containing the config for all officially released version of baz. So you
can rebuild any of them from there.

>One vague idea I have is creating a fourth project. Doing so would
>ensure that the exact combination would always be easily retrievable.
>But it seems that any fixes applied to this tree would be hard to then
>move to the individual projects.
>
>
I have done this as well. One 'integration-project' which integrates
everything, and individual sub-projects.
Because arch uses a special unique id for each file, merging patches
back and forth is actually pretty easy to do.
When you are merging into the integration-project, all files are looked
up by id, so it doesn't matter where they are in the directory structure.
When you are merging from the integration-project, patches whose file id
does not exist, are put into a "+missing" directory. But otherwise the
merge continues without complaint (it should probably complain a little
bit more than it does, but it still succeed).
The only current problem that I know of is actually a bug. When you add
a new file, the id of the directory it was added in is not properly
recorded. So that when you merge it back into the integration-project,
it will be added in a directory with the same path.
For example:
    $integration/
       lib1/
          file1.c
          file2.c
       lib2/
          file3.c
          subdir/
             subsubdir/
                something.c

    $lib1/
         file1.c
         file2.c
         file4.c <= this file was added
    $lib2/
         file3.c
          subdir/
             subsubdir/
                something.c
                new-something.c <= added as well


If you make a change to $lib1/file1.c it will merge back into
$integration/lib1/file1.c without any problem.
However, adding file4.c will be added into $integration/file4.c
And the new-something.c will be added as
$integration/subdir/subsubdir/new-something.c when you want it as
$integration/lib2/subdir/subsubdir/new-something.c

This is something that has been noticed a few times, but as far as I
know is not fixed in either baz or tla. It isn't hard to work with, but
it is a gotcha that you need to be aware of.

>Alternatively, I could branch each project giving them related names.
>Doing so would make merging fixes between branches easy. Unfortunately,
>it slightly increase the chance of human error retrieving an exact
>combination of revisions.
>
>I'm leaning toward the second course, but would appreciate any advice
>from more experienced users first.
>
>
I think a separate project containing "configs" is the current
best-practice. It is what both baz and tla use (to keep track of
libhackerlab, arch source, package framework, etc.)

As I mentioned, I've done both. I did the integration-package because I
was tracking someone else's CVS tree, and it was easier to track as 1
project, but on windows arch gets really slow with a lot of files, so I
broke it up for speed.
With the new "baz build-config" supporting switching or just updating in
place, configs become even nicer. So it's probably what I would recommend.

John
=:->

signature.asc
Description: OpenPGP digital signature