using bazaar to manage different but related product lines

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-08-19 20:56, Chris Hack wrote:
> New question #234277 on Bazaar:
> https://answers.launchpad.net/bzr/+question/234277
>
> Hi,
>
> I am currently trying to create a project that is based on a
> single common core. The idea is that the products will be
> separate, unique products with their own features and
> specifications, but that they are related to one another via that
> common core. I want to be able to use versioning software to keep
> track of the changes in the product lines and update the separate
> products somewhat automatically when an update is made to the
> common core. Is this possible to do with bazaar? If so, how might
> this be accomplished? I've been playing around with this for a few
> days and for the life of me I can't figure out how that could be
> done. Help would be greatly appreciated. I am a new user to any
> kind of version control software and chose bazaar as a first test
> because it seemed to be a very highly rated VCS platform with a
> short learning curve. Thank you in advance for your help.
>
>
> -Chris
>

To start with, Bazaar doesn't provide a lot of assistance for "managed
divergence". Specifically, if you merge A => B and then B => A, bazaar
will try to make the two branches identical.

Generally to do what you're asking, you need to make sure that shared
changes flow directly into the common core, and then only from there
to the other products. So something like:

   common
  / | \
prod1 2 3

then when you have a new common bit, you would do:

 cd common
 edit files, etc
 bzr commit -m "add new feature"

 cd ../prod1
 bzr merge ../common
 bzr commit -m "bring in the new feature"

 cd ../prod2
 bzr merge ../common
 bzr commit -m "bring in the new feature"

etc.

The main discipline is that if you develop something on eg 'prod1' and
realize after that you actually want it to be common, you should
"cherrypick" it back to common, and not do a full merge back to common
(which would bring in all the other changes that you don't want to be
common.)

You can still use merge with "bzr merge -r PRE..LAST" (so bzr merge -r
- -3..-1 to just bring in the changes from the last two commits).

Does that point you in a reasonable direction?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIS/sQACgkQJdeBCYSNAAP+rACeKQBy/s2LBOAQqfQBEapFVR8S
w8QAoMF50rncZ92yN8CuwHWa32tHQYl+
=Zt8W
-----END PGP SIGNATURE-----

John,

Yes, thank you for at least trying to point me in the right direction. I do have a couple more basic questions for you though. First, if I was to implement the type of repository you outlined, how would I set it up? Would it be a colocated, feature, plain or shared repository? Do I set up the repository in the common directory or in a directory that contains common? Again, I'm new to the whole concept of software versioning so please bear with me.

My next question is if bazaar doesn't do managed divergence support, is there a VCS platform that does? That is the main thing that my software engineer team is looking for, second only to a VCS platform that has a relatively small learning curve.

Thank you again for your time.

-Chris

Darcs is the only VCS I know of that explicitly uses the model of a set of
patches rather than a directed graph of revisions. It runs into problems
when you have a huge number of changes (set difference of 100k patches gets
a bit big to think about). It also doesnt track history in the same way
(you aren't guaranteed to be able to restore to any old historical version
that you didn't explicitly tag).

For the layout it depends on the size of your source. For modest sizes, I
would use a shared repo with trees for simplicity. So you have

bzr init-repo .../repo
bzr init .../repo/common

And then you have your source tree under common.
Then each project you:
cd .../repo
bzr branch common project

That gives you another directory with your whole tree.

If the source is large enough that multiple whole trees is a problem you
would want something colocated. (Or a shared treeless repo with a
lightweight checkout.) I won't confuse you with the details, unless you
need it.

John
=:->
On Aug 20, 2013 7:41 PM, "Chris Hack" <email address hidden>
wrote:

> Question #234277 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/234277
>
> Status: Answered => Open
>
> Chris Hack is still having a problem:
> John,
>
> Yes, thank you for at least trying to point me in the right direction.
> I do have a couple more basic questions for you though. First, if I was
> to implement the type of repository you outlined, how would I set it up?
> Would it be a colocated, feature, plain or shared repository? Do I set
> up the repository in the common directory or in a directory that
> contains common? Again, I'm new to the whole concept of software
> versioning so please bear with me.
>
> My next question is if bazaar doesn't do managed divergence support, is
> there a VCS platform that does? That is the main thing that my software
> engineer team is looking for, second only to a VCS platform that has a
> relatively small learning curve.
>
> Thank you again for your time.
>
> -Chris
>
> --
> You received this question notification because you are an answer
> contact for Bazaar.
>