Re: [Gnu-arch-users] Genealogical branches

[Andrew Suffield]

On Sat, Feb 18, 2006 at 12:21:35AM -0600, Ron Parker wrote:
> The issue is that I want to have a directory which will ultimately
> contain selected portions of the final product's genealogy in addition
> to other files. For example:
> 
>        README
>        ...
>        test1
>        test2
>        test3a
>        test3b
>        ...
> 
> And each testN file is developed sequentially from the preceding one.
> Now this directory doesn't retain every iteration of a file, just
> selected snapshots.  But I want to retaining full history and
> maintainability across all the steps. The thing is, since I'm not
> perfect, there have been occasions where I have found mistakes in an
> earlier step that need to be corrected and propagated to the later
> ones.
> 
> So the basic idea is create README & test1 as step1. "Branch" that to
> step2 and rename test1 to test2.  Hack on test2. Branch that to step3
> and continue ad nauseum.  Now checkout step1. Make a fix to test1.
> Then "pull" or "roll" the fix forward into the descendants in the rest
> of the branches.
> 
> Finally I need a genealogical branch, call it "final", into which I
> pull the contents of all the various steps.  It should be a
> conglomerate showing the selected genealogy.
> 
> In other words, it should have a copy of the latest test1 from step1,
> the latest test2 from step2, etc. and since README was never renamed
> it should contain the README from whatever the latest step was.
> 
> Does this make sense?  I know its a fair abuse of an SCM, but I
> considered it a nice challenge and it really helps me to not be lazy
> and only apply fixed to the later steps leaving the prior ones with
> typos or other errors.

I think this is an instance of the 'copy' problem. Arch doesn't
support it directly because nobody has been able to come up with (a) a
problem where it's actually useful, and (b) a solution that makes any
kind of sense at all. If I have understood what you want correctly,
you might have finally found a case where you actually want this.

The idea is that you fork a file into two new files ('copy'
operation), and henceforth there is some kind of relationship between
these two files. That's where the problems start - when you apply a
patch to 'old' what should you do with 'new'? Possible options:

 - ignore 'new', apply the patch to 'old'
 - ignore 'old', apply the patch to 'new'
 - attempt to apply the patch to both files
 - throw a conflict and let the user work it out

And as far as anybody can guess, you might want any of these four in
any given scenario, so now you have to explain to arch what to
do. That's about where we dropped the subject (many years ago), on the
basis that nobody had a good solution or a reason to do it. Nobody is
really sure whether it *can* be solved (svn needs to solve this in
order to get merging to work in all cases, but hasn't yet - they just
have some cases where merging fails, instead).


However, you can arrange things in a way that I think might solve your
problem, without solving the copy problem, if you're willing to accept
a few modest variations in the requirements:


Let's say you create a branch test--step1, containing whatever you
want to go in test1. At some point later, you branch it to
test--step2, and later still, that is branched to test--step3a and
test--step3b.

Now, you can apply later changesets from test--step1 to any of the
other branches, as and how you feel like it - nothing automatic
happens here, but you can get the job done. Your 'roll the fix
forward' is just a normal merge operation.

Your 'final' branch never exists as a branch at all. It's actually a
configuration, containing this:

./test1 test--step1
./test2 test--step2
./test3a test--step3a
./test3b test--step3b

And you run 'tla build-config' and 'tla update-config', which will
create and update the directory containing the latest versions of all
those branches (since the config doesn't specify any revisions).


I believe that will accomplish what you want - it's not very
automated, but it's not difficult to script this stuff either. It does
mean that test1/test2/test3a/etc are all directories instead of files,
but that shouldn't be difficult to handle. You don't have a 'final'
branch, but you don't want to commit to it anyway, so you don't need
one (you can't have a branch here without solving the copy problem).

signature.asc
Description: Digital signature