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

[Jan Hudec]

On Wed, Sep 20, 2006 at 03:02:21PM -0400, 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.
> 
> 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...

I think you understand it wrong here. In all of mercurial, git and
bazaar a mirror /always/ contains the /whole/ history. The reason why
svk is not distributed enough -- or in fact why it's not 'distributed'
at all(1) -- is, that mercurial, git and bazaar mirrors are exactly
equivalent to the 'master' and the revisions on them keep their
identity. That's not the case with svk.

(1) Distributed (operating) systems are usually defined with a set of
    requirements, among them being that resources (which are revisions
    in case of version control system) are identified independently of
    their location and can be rellocated transparently to clients.

    As far as I know, you can't really svk mirror --rellocate to point
    to another mirror of what you mirrored before. And would this work
    in svk:
    
        Let's have master branch a in repo A. Mirror A/a into B/a,
        branch it to B/b (local branch) and do a change. Now mirror A/a
        to C/a and B/b to C/b and so svk smerge C/b C/a.

    Throw in some intermediate branches, eg:

        Mirror A/a to B/a. Branch B/b1 from B/a. Do change on B/b1.
        Branch B/b2 from B/b1. Do another change. Now mirror A/a to C/a
        and B/b2 (only -- the C admin might have no knowledge about
        B/b1) to C/b2. And svk smerge C/b2 C/a. Still works?

    Further modifications of this scheme, like moving the B/b1 into yet
    another mirror etc. are possible.

    Now Mercurial, GIT and Bzr all operate on just DAG of revisions
    and keep revision identity across mirroring, so no matter how many
    mirrors you complicate the situation with, it will still be exactly
    the same for them. AFAIU svk will miss the need to copy some
    revision (because it's on another branch) or not notice some
    revisions are the same (because they are mirrored from different
    places, though they originate from the same through chains of
    mirrors) sooner or later and fail to do the operation.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb at ucw.cz>