Re: Maintaining 'stable' and 'development' versions of a repository (hopeless newbie question)

Aron Ahmadia wrote:
> I want the stable repository to effectively be a few changesets behind the
> development version, with the ability to push changes in the development
> version to the stable version on a changeset-by-changeset or file-by-file
> basis.
>
> The problem is, I don't know exactly how to do this in Bitkeeper (I wouldn't
> even have a clue how to do it in another tool), or perhaps I'm taking the
> wrong approach.  What I've done so far is to to create a clone of the
> development repository and call it stable.  Then I pushed a bunch of great
> new changes into development.  What are my options for pushing changes from
> development into stable?  I don't know what Bitkeeper commands would allow
> me to selectively pick changesets from one repository on my system and apply
> them to another.
>
> Forgive me, I'm actually still really new to the version control game, and
> I'm not sure I'm even using the proper terminology.

You raised a very important issue (IMHO), in which bitkeeper does actually have 
a weakness - at least, it is not totally intuitive how to achieve the desired 
mode of operation. The problem is, that if you have three changesets B, C and D 
(as an example) in the development branch, with D being the latest, and the 
stable branch is at changeset A, you can not pull over changeset D without 
pulling B and C at the same time. Such a thing would be called "cherry-picking", 
and is a feature which is planed for future bitkeeper versions, IIRC.

What you can do to achieve such a mode of operation is to clone a lot. Cloning 
is generally a good idea with bk, and using the clone option "-l" (use hard 
links), it is very efficient, too. Thus, for each independent feature in the 
development branch, you create a new clone in which to implement it. For the 
example above, you'd use three clones, each with a changeset B_1, B_2 and B_3. 
You can then move these changesets around between all repositories.

Also, in your case, you should probably maintain another named branch next to 
"stable" and "development" which would be called "testing". This makes sense 
because moving new features into the "stable" branch is not a good idea (as it 
will sooner or later make the branch unstable). Instead, let the users who want 
to test these new features do this by giving them the "testing" branch.

 Joachim

--
Joachim Worringen - NEC C&C research lab St.Augustin
fon +49-2241-9252.20 - fax .99 - http://www.ccrl-nece.de