[Top][All Lists]

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

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

From: John Arbash Meinel
Subject: Re: [Gnu-arch-users] Question about branching a subset
Date: Sun, 03 Apr 2005 09:51:13 -0500
User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)

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


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.


Does anyone have an idea how I can resolve this problem?

Dick Knol <address@hidden <mailto:address@hidden>>

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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