help getting a clue about tracking changes in an integrated library

[Stephen J. Turnbull]

Chris Hecker writes:

 > Thanks for the detailed response.  I need to digest it, but here
 > are some questions/comments:
 > 
 > 1.  the "poor man's nested branches" approach seems scary/hacky?

With a good VCS, nothing should scare you (except a disk failure).
Bazaar is a good VCS. :-)

The main issue that you will run into using the "poor man's approach"
that you don't get in a real nested branch or the monolithic approach
is that you have to keep track of which versions of "lib" go with
which versions of your project.  If changes to "lib" are infrequent
and immediate (ie, you always automatically upgrade everything to new
versions of "lib"), this is not a big problem: commit dates tell you
almost as much as revision IDs do.

If different versions of your project will depend fairly strictly on
different versions of "lib", then this is going to get risky or
tedious, depending on whether you try to keep good records of which
version goes with which.  So, for example, you could implement a
script which appends the current revision ID for "lib" to the commit
log of every commit in the parent project.  Hacky, yes.  Good enough
until Bazaar gets real nested branches about a year from now (maybe
sooner)?  The final decision is yours, of course, but if upstream(s)
are fairly slow-moving compared to your project, I would say, "yes,
good enough."

 > 2.  if I have my main code in a shared repo, and then as siblings I
 > have the lib-upstream and lib-modified, then I can branch
 > lib-modified into the main code at an arbitrary location?
 > In other words, your step 15 in the "monolithic" approach, I can do
 > something like this:
 > 
 > shared repo -+- trunk -+- src
 >               |         |
 >               |         +- lib
 >               |
 >               +- lib-mod
 >               |
 >               +- lib-orig
 > where lib is a branch of lib-mod?

No.  That works in the poor man's nested branch, but not in the
monolithic approach.  In the monolithic approach, each branch contains
both your project and the separate lib, and they must be laid out the
same way.  The way I think of the procedure I posted earlier is quite
different from the actual history of your project.  Something like

1.  You hear from your friend about this cool library and his mods.
    You think, "hey, I know what to do with that!"
2.  In planning you realize that you need to deal with his mods as a
    separate branch from the upstream version.
3.  So first you create a "pristine" branch synced to the upstream of
    the library, but you locate it in the appropriate place in your
    project.  No mods, none of your code ever go in here.
4.  Then you branch and apply the patch from your friend.  This also
    is synced, but to your friend's version.  His mods, but none of
    your code are here.
5.  Finally, you branch again, and start populating that branch with
    your great ideas, around the code you got from your friend.

A little weird, I admit, but it will work, and allow Bazaar to do as
much of the tedious accounting as possible.

Even if you start from your actual history, then make branches with
upstream only, your friend's mods only, and a trunk, you won't be able
to mix and match versions of your code with versions of "lib" very
easily.  Rather, each branch will match specific versions of "lib"
with specific versions of your code, and other mixtures will require
some creativity to achieve, and manual recording or further branching
to remember.  This is a potential deficiency in the monolithic
strategy.  The two strategies make different things easier:

Monolithic: reverting to a version of your code plus the corresponding
version of "lib" is easy, because they share history.

(Poor man's) nested branch: changing the version of the "lib"
independently of your code is easy, because they don't share share
history.

True nested branch: you can do both, because the VCS keeps track of
which version of "lib" was in use with a version of your code, but you
can still use the VCS to checkout a different version of "lib" without
affecting the checkout of your code.  If you decide you like that
combination better, you just commit the whole project.  Unfortunately
bzr doesn't support this yet.  It's probably easy to migrate from poor
man's nested branches to true nested branches when the feature becomes
available (but not necessarily trivial).

 > 3.  I assume I can have multiple different libs handled this way,
 > as long as they're all in the shared repo?

Yes.  Actually shared repos are an optimization; bzr doesn't care
where your branches are, it's just that you can save space by sharing
the common versions (ie, from before the branch), and it makes certain
workflows a lot more convenient.  Specifically, branching is way
faster in a shared repo because you don't need to copy project content
or history; you just need to copy the metadata that defines a branch.

 > 4.  To your point below, I do have history in the main project, and
 > I want to preserve that obviously, so I'll need to move that into a
 > shared repo.  I also push that out to a server...can I push the
 > whole shared repo out the same way?

AFAIK, no.  Shared repos are not first class objects in bzr in some
sense.  Improving the UI for shared repos is on the agenda, but not at
the top, AIUI.

 > 5.  The loom thing sounds interesting, yet also scary.

I don't think you need to be terribly scared.  After all, everything
you do is properly recorded in the VCS.  The only thing is that you'll
be pioneering, so you'll need to invest some time in understanding it
yourself -- there won't be a lot of easy recipes around.  And you may
figure out a few months down the line that the whole thing would have
been much simpler or much more effective "if only I had known!"  But I
doubt you'll waste obscene amounts of time on it, and the potential
for catastrophic data loss and the like is no higher than for Bazaar
itself, I should think.