[svk-devel] Re: Mercurial (and NOT svk) chosen as Distributed SCM for OpenSolaris... Do we "Know" the reasons for rejection?

[F. Javier Jarava]

On Wed, Sep 20, 2006 at 03:02:21PM -0400 or thereabouts, John Peacock wrote:
> F. Javier Jarava wrote:
> >My own line of thinking, having done some "study" of SCM tools prior to
> >settling on SVK (I was a happy user of BitKeeper until they changed the
> >terms), is that SVK is not "distributed enough".
> 
> I think you are probably right, but that it was a deliberate design 
> choice on the part of CLKao (AFAICT).  SVK allows you to mirror any or 
> all of a remote repository and access that portion of the history that 
> you mirrored offline.  AIUI, tools like Mercurial allow you to mirror a 
> repository at a point in time, then keep it synced with the main repo as 
> well as multiple peer Mercurial instances.  However, only the primary 
> repository has the entire history.

I'm not too sure about Mercurial (I looked at it over 1 yr. ago, and
dind't get to the "install and give it a go" point), but I believe the
model they use is more like Git and BK: Your depot is a "full copy" of
other depots. As such, there is no centran repo you mirror from;
instead everbody's repos are "equal", and you can pass around csets that
involve more or less history.

Personaly, I "loved" the bk model in that each repo was a true unit and
you could just create relationships between them (you had "parent" and
"child" repos, but that was more to show where your initial data had
come form, than to mark an strict hierarchy).

The idea behid Git is something like that: each revision is identified
by its SHA1 sum, so it's simple to find "common ancestors" in the
history of two different depots. The only drawback I found at the time I
was looking for a new "home" for my data us is that Windows support was
between sub-par and nonexistant ;)

> SVK is a fat mirror, as opposed to Mercurial or GIT which are thin 
> mirrors.  It's just a different way to approach the problem.  Needless 
> to say, I prefer SVK for now; if someone would write a driver to store 
> the "local" mirror in a remote SVN repository, that could change the 
> whole dynamic...
> 
> John
> 
> -- 
> John Peacock
> Director of Information Research and Technology
> Rowman & Littlefield Publishing Group
> 4501 Forbes Boulevard
> Suite H
> Lanham, MD  20706
> 301-459-3366 x.5010
> fax 301-429-5748
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel