Multiple repositories or Branches?

[Tony Mechelynck]

On 08/06/10 23:47, Ken Halprin wrote:
> After reading through the help files to get a feel for managing
> releases, I’m wondering if there’s a preferred method – using multiple
> repositories or branches? My entire project will consist of many (about
> 40) repositories representing components of the system. It seems like
> making multiple folders to contain version-specific repositories would
> be the easiest way to go. For example:
>
> Product\1.0\<all the repositories here and below>
>
> Product\1.1\<all the repositories here and below>
>
> If I were to use branches (and if I understand using branches
> correctly), I would have to create a branch in each of the repositories
> of my project to have version-specific branches for all of the
> components…that seems a bit tough to manage.
>
> Any thoughts? Am I going about this the right way?
>
> Thanks,
>
> Ken
>
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

Well, you could have branches inside the repository, and as each branch, 
well, branches off, it becomes "release branch n.nn" while the "default" 
branch remains the bleeding edge (NOT the stable release). Then each 
branch would contain the whole project, which would not preclude it 
being divided in directories according to the components of the system.

If you want to compile, let's say, "branch 1.3", "branch 1.4" and 
"default" (the future branch 1.5) in parallel, then you could for 
instance create three parallel working copies by means of the "share" 
extension, where each of them would be "updated" to the latest versions 
of its branch's files. Or you could pull three clones of the master 
repository, one for each branch. (If you compile the different versions 
on different machines, each one must have its own clone. If you compile 
two or more on a single machine, you can "share" them, doing only one 
pull for them all. If merges are necessary you will still have to do 
them separately for each concerned repository.)

Then as updates happen, each new changeset would be assigned to the 
proper branch at commit time (by the fact that the developer doing the 
commit has been working on a clone of the repository, updated to the 
apropriate branch), and that branch label is of course kept by the push. 
So the master repository would contain all changesets for all branches, 
but not necessarily a working copy; and someone going to work on some 
nondefault branch would for instance start his work with

	hg clone -U https://hg.example.com/ 1.4
	cd 1.4
	hg heads
	hg update xxxx
		where xxxx is the revision of the desired branch head.

If your project is really huge, you could have a repository inside the 
repository, like Mozilla does, where there is for instance a 
"comm-central" repository for SeaMonkey, Thunderbird and Calendar, and 
the first thing one does before compiling one of these is running a 
"client.py" script which not only pulls and updates that, but also pulls 
and updates a clone of the "mozilla-central" repository, containing the 
sources for Firefox, Toolkit, etc., many of which are needed to compile 
SeaMonkey or Thunderbird. (I don't know the exact details.)


Best regards,
Tony.
-- 
"Why was I born with such contemporaries?"
		-- Oscar Wilde