Re: [Gnu-arch-users] Question about branching a subset

[John Arbash Meinel]

Dick Knol wrote:

> I have to implement a versioning system for my company, but the
> problem is that there are very many files involved. A lot of them are
> text, others are encrypted source, thus binary. There are also a lot
> of binary object files. The structure of the environment works with
> different layers (one for our software vendor, one for customizations
> FROM our vendor, and one for all our own developments). These are also
> divided into subcategories for each site, because not all software is
> for all sites, and a CORE for something that is for all sites.
>
> Furthermore, for every site there is a production and
> test-environment. The test-environment only contains software that is
> in test, when it is OK, it will be removed from test and put into
> production. The test environments also look in the production
> environment for all object-files it hasn't itself.
>
> I came up with the idea to work with little projects. Develop in a
> project, copy source from the destination environment, or create new.
> Then, when finished, it must be delivered to test. Sometimes there
> must be more changes after testing, so it must be redelivered to test.
> When testing completes, it will be delivered to prod.
>
> Test will be a branch of Prod, only containing the needed files for
> testing. What I want is to create a branch (as a project) from the
> target production environment. But it must only contain the source
> file I want in it. Then, when all is finished, the branch is merged
> with the target test environment. When testing completes, the patch is
> applied to prod.
Well, this is actually possible, though it is not quite straightforward.

$ tla tag -S $archive/project--prod--0.1 $archive/project--test1--0.1
$ tla get $archive/project--test1--0.1 test1
$ cd test1
$ tla rm blah blah blah # Any files you *don't* want in test
$ tla mv path/to/source . # Not necessary, but you probably want the
                         # file you are working on in the root
                         # directory

$ tla commit -s "Pruned all unnecessary files"
$ cd ..
$ tla get $archive-project--prod--0.1 prod
$ cd prod
$ tla sync-tree $archive/project--test1--0.1  # [1]
$ tla commit -s "Syncing to test1 branch."
$ cd ../test1
<hack hack hack>
$ tla commit -s "did some work."
<hack hack hack>
$ tla commit -s "did more work"
$ cd ../proj
$ tla star-merge $archive/project--test1--0.1
<review changes>
$ tla commit -s "Merged changes from test1 branch."
# oops there is still a bug
$ cd ../test1
<hack hack>
$ tla commit -s "Fixed another bug."
<test test>
$ cd ../proj
$ tla star-merge ...

Anyway, the real trick here is the [1]. Basically what happens is that
you create a test branch, and then you remove all the extraneous files.
Committing this creates a single changeset which describes the file removal.
sync-tree is a command which tells the prod branch that it should
pretend to already have merged that changeset (since you obviously don't
want to ever accidentally remove all the files from prod).

From then on, because the files have the same arch id, whenever you
merge from one tree to the other, the right files should be updated.

> Is it possible to work with Arch in this way. Seems to me it doesn't,
> because Arch only works with whole trees.
>
> Another (better) option may be that test is a full environment, not
> just a subset that needs to be tested. This way branching test should
> be simple, and merging changes from test to prod should be
> straightforward. Only the project-branches don't fit into this picture.
Why not? I can have

$archive/project1--prod--0.1
$archive/project2--prod--0.1
$archive/project1--dev--0.2
$archive/project2--dev--0.2
$archive/project2--test--0.2
...
$archive/project2--test-for-fix1--0.2
$archive/project3--bug00241--0.1

In arch, you can have a complete branch for anything you want, often
times it is good to create a branch for each bugfix, since then the
changes are encapsulated well. (If the fix is simple enough, then
possibly they would be encapsulated by a single patch.)

I would probably recommend this way over the other way, but it depends
on your needs.

I'm also a bigger fan of having a configs based working directory with a
lot of nested subprojects. This has a few advantages, your libfoo can be
shared easily by project1 and project2, *and* it can have a different
versioning scheme. (project1 v1.2 can use libfoo v2.3, etc)
Also, it helps speed up tla when working with lots of files.
It's a little bit tricky to make sure that cross-(sub)project changes
both get committed (because you have to cd into each subproject and commit).
I use a wrapper script that acts recursively for "tla changes", which I
run frequently to make sure that none of the subprojects have
uncommitted changes.

John
=:->

> Does anyone have an idea how I can resolve this problem?
>
> --
> Dick Knol <address@hidden <mailto:address@hidden>>

signature.asc
Description: OpenPGP digital signature