help getting a clue about tracking changes in an integrated library

[Chris Hecker]

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

Scary is multidimensional; data loss is not the only axis.  Another axis 
is spending an infinite amount of time on something.  I mean, simply 
copying the source into the trunk has a well understood set of 
disadvantages and is bounded in terms of my time invested.  That's 
getting more appealing as this thread grows.  :)

>> where lib is a branch of lib-mod?
> No.

Ah.  Ugh.

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

Yeah, this seems like it's a requirement always, no?  I mean, if you 
can't sync to a version and get something that builds and is correct for 
that point in time, then it seems like you're not really getting the 
advantages of using a vcs.  I guess different people have different 
priorities, but that seems fundamental to me.

It definitely sounds like "nested trees" are what I want from reading 
the design page.  Is that work underway?

Here's another question:  let's assume I'm willing to give up having the 
code in different branches, is there any way to use bzr to help with the 
merges between unrelated branches?  In other words, assume I'm willing 
to just copy the "final" code into my trunk, what's the best way to 
reduce my manual merging?  It sounds like maybe just keeping a separate 
repo for this code, with lib-orig, lib-mod, lib-mine, and then copy 
lib-mine into its place in my tree (and vice versa).  That way I have a 
copy in the main branch, which is vital for reverting, but also bzr can 
help with the updates?  The downside there is bzr has no knowledge that 
lib-mine and the lib in the trunk are related, I guess?

Thanks,
Chris




On 2010/09/22 01:52, Stephen J. Turnbull wrote:
> 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.
>