Which VCS besides git?

Which VCS besides git?

[Kārlis Repsons]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

People,
which VCS besides git provide chaining of commits with help of some 
cryptographic hash function, warning about or not allowing commits to be 
deleted on an equivalent of pull action, so that all added pieces of data can 
be retained securely on client side?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Which VCS besides git?

[Shawn O. Pearce]

K??rlis Repsons <karlis.repsons@gmail.com> wrote:
> which VCS besides git provide chaining of commits with help of some 
> cryptographic hash function, warning about or not allowing commits to be 
> deleted on an equivalent of pull action, so that all added pieces of data can 
> be retained securely on client side?

Most of the distributed VCS systems do this.  I know Mercurial is
functionally identical to Git in this regard.  Maybe even Monotone
and Bazaar are as well, but I'm less familiar with those.

-- 
Shawn.

Re: Which VCS besides git?

[Kārlis Repsons]

[-- Attachment #1: Type: Text/Plain, Size: 609 bytes --]

On Tuesday 02 March 2010 15:28:21 Shawn O. Pearce wrote:
> K??rlis Repsons <karlis.repsons@gmail.com> wrote:
> > which VCS besides git provide chaining of commits with help of some
> > cryptographic hash function, warning about or not allowing commits to be
> > deleted on an equivalent of pull action, so that all added pieces of data
> > can be retained securely on client side?
> 
> Most of the distributed VCS systems do this.  I know Mercurial is
> functionally identical to Git in this regard.  Maybe even Monotone
> and Bazaar are as well, but I'm less familiar with those.
And svn doesn't?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Which VCS besides git?

[Shawn O. Pearce]

K??rlis Repsons <karlis.repsons@gmail.com> wrote:
> On Tuesday 02 March 2010 15:28:21 Shawn O. Pearce wrote:
> > K??rlis Repsons <karlis.repsons@gmail.com> wrote:
> > > which VCS besides git provide chaining of commits with help of some
> > > cryptographic hash function, warning about or not allowing commits to be
> > > deleted on an equivalent of pull action, so that all added pieces of data
> > > can be retained securely on client side?
> > 
> > Most of the distributed VCS systems do this.  I know Mercurial is
> > functionally identical to Git in this regard.  Maybe even Monotone
> > and Bazaar are as well, but I'm less familiar with those.
> 
> And svn doesn't?

I don't know about SVN.  I only used it for a few months between
CVS and BitKeeper.  After that, I jumped pretty fast into Git and
didn't care about how Subversion works internally.

You might want to ask on the SVN mailing list rather than the Git
mailing list about SVN specific details...

-- 
Shawn.

Re: Which VCS besides git?

[Jakub Narebski]

Kārlis Repsons <karlis.repsons@gmail.com> writes:

> which VCS besides git provide chaining of commits with help of some 
> cryptographic hash function, warning about or not allowing commits to be 
> deleted on an equivalent of pull action, so that all added pieces of data can 
> be retained securely on client side?

Could you rephrase your request in more clear way?

If you want to know which VCS beside Git use cryptographic hash
function over commit info and commit parentage as commit id, then both
Monotone (from which Git borrowed this idea) and Mercurial use it.

Bazaar, if I understand it correctly, and from what I remember, uses
some UUID which includes commit digest as a commit identifier, but I
don't know if Bazaar have immutable history.

In Subversion you can change svn:log (or something like that)
property, i.e. change commit message, after the fact; I don't think
there is any check for that.  CVS doesn't support changesets, so it is
out of question.

I don't know about Darcs, or BitKeeper, or ClearCase, or Perforce.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Which VCS besides git?

[Kārlis Repsons]

[-- Attachment #1: Type: Text/Plain, Size: 833 bytes --]

On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:
> Kārlis Repsons <karlis.repsons@gmail.com> writes:
> > which VCS besides git provide chaining of commits with help of some
> > cryptographic hash function, warning about or not allowing commits to be
> > deleted on an equivalent of pull action, so that all added pieces of data
> > can be retained securely on client side?
> 
> Could you rephrase your request in more clear way?
> 
> Bazaar, if I understand it correctly, and from what I remember, uses
> some UUID which includes commit digest as a commit identifier, but I
> don't know if Bazaar have immutable history.
On top of what you wrote already, I'd like to know which VCS have immutable 
history, which can all be stored (say, gradually accumulated) on clientside? I 
hope, that explained the idea...

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Which VCS besides git?

[Ben Walton]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Excerpts from Kārlis Repsons's message of Tue Mar 02 11:22:16 -0500 2010:

> On top of what you wrote already, I'd like to know which VCS have
> immutable history, which can all be stored (say, gradually
> accumulated) on clientside? I hope, that explained the idea...

Monotone does have immutable history (unless you munge the db by hand)
and is distributed (full history in each repo, good merging, etc).

I enjoyed mtn for a few years before getting hooked on git.  I've
found git much more pleasurable (and powerful) to use though.

HTH.
-Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Which VCS besides git?

[Jakub Narebski]

Kārlis Repsons wrote:
> On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:
> > Kārlis Repsons <karlis.repsons@gmail.com> writes:

> > > which VCS besides git provide chaining of commits with help of some
> > > cryptographic hash function, warning about or not allowing commits to be
> > > deleted on an equivalent of pull action, so that all added pieces of data
> > > can be retained securely on client side?
> > 
> > Could you rephrase your request in more clear way?
>
> On top of what you wrote already, I'd like to know which VCS have immutable 
> history, which can all be stored (say, gradually accumulated) on clientside? I 
> hope, that explained the idea...

As I wrote, all VCS which use cryptographic hash function (digest) for
commit identifier have immutable history.

All distributed VCS (DVCS) store whole[*] history with checkout.  There
isn't (beside _social_ reasons) any distinction between different repos:
there is no client - server model (so no "clientside"), but rather peer
2 peer model.  See http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model
(from OSS ones I'd say Git, Mercurial, Bazaar, Darcs, Monotone count).


[*] well, with possibly some exceptions, like shallow clone, or selecting
    branches to clone.

-- 
Jakub Narebski
Poland

Re: Which VCS besides git?

[Felipe Contreras]

On Wed, Mar 3, 2010 at 3:41 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Kārlis Repsons wrote:
>> On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:
>> > Kārlis Repsons <karlis.repsons@gmail.com> writes:
>
>> > > which VCS besides git provide chaining of commits with help of some
>> > > cryptographic hash function, warning about or not allowing commits to be
>> > > deleted on an equivalent of pull action, so that all added pieces of data
>> > > can be retained securely on client side?
>> >
>> > Could you rephrase your request in more clear way?
>>
>> On top of what you wrote already, I'd like to know which VCS have immutable
>> history, which can all be stored (say, gradually accumulated) on clientside? I
>> hope, that explained the idea...
>
> As I wrote, all VCS which use cryptographic hash function (digest) for
> commit identifier have immutable history.

That's not exactly correct. Monotone works very differently; a
revision doesn't include the ancestry, that's handled in a separate
structure, so the revision hash doesn't tell you anything about the
ancestry. In fact, a revision doesn't contain anything, the data is
handled by "certs", and certs can be added later.

For example, it's possible to clone a repository and then add a second
commit message to a bunch of revisions. The revision hash doesn't
change. Instead, they ensure security by signing every piece of data
about a commit (commit date, author, commit message). So it's possible
to have multiple commit dates, authors, messages, etc. each signed by
a different person.

I'm not really fond of this approach :P

-- 
Felipe Contreras

Re: Which VCS besides git?

[Bruce Stephens]

Felipe Contreras <felipe.contreras@gmail.com> writes:

[...]

> That's not exactly correct. Monotone works very differently; a
> revision doesn't include the ancestry, that's handled in a separate
> structure, so the revision hash doesn't tell you anything about the
> ancestry.

Not so.  Long ago that was the case (ancestry was via certs), but that's
not been the case for a long time.  There are (in retrospect) obvious
advantages in including the ancestry in the hash.

> In fact, a revision doesn't contain anything, the data is handled by
> "certs", and certs can be added later.

Revisions lack date, author, branch, commit message, but include
ancestry and the actual changes (which files/directories have changed
and how).

> For example, it's possible to clone a repository and then add a second
> commit message to a bunch of revisions. The revision hash doesn't
> change. Instead, they ensure security by signing every piece of data
> about a commit (commit date, author, commit message). So it's possible
> to have multiple commit dates, authors, messages, etc. each signed by
> a different person.
>
> I'm not really fond of this approach :P

It has the nice feature that many people can create merges, and if they
create exactly the same merge (from exactly the same parents) then only
one revision results (just with multiple certs decorating it).

(Monotone has changed since I last used it but I think the above is
still true.  There's been discussion about larger certs (rather than
having separate certs for branch, date, author, message, to have just
one covering the usual combination) AFAIK that hasn't happened yet.)

Re: Which VCS besides git?

[Felipe Contreras]

On Wed, Mar 3, 2010 at 2:12 PM, Bruce Stephens <bruce.stephens@isode.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> [...]
>
>> That's not exactly correct. Monotone works very differently; a
>> revision doesn't include the ancestry, that's handled in a separate
>> structure, so the revision hash doesn't tell you anything about the
>> ancestry.
>
> Not so.  Long ago that was the case (ancestry was via certs), but that's
> not been the case for a long time.  There are (in retrospect) obvious
> advantages in including the ancestry in the hash.

Ah, I looked quickly ad one db and still saw 'revision_ancestry' being
used. I guess they decided to keep the information redundant.

>> In fact, a revision doesn't contain anything, the data is handled by
>> "certs", and certs can be added later.
>
> Revisions lack date, author, branch, commit message, but include
> ancestry and the actual changes (which files/directories have changed
> and how).
>
>> For example, it's possible to clone a repository and then add a second
>> commit message to a bunch of revisions. The revision hash doesn't
>> change. Instead, they ensure security by signing every piece of data
>> about a commit (commit date, author, commit message). So it's possible
>> to have multiple commit dates, authors, messages, etc. each signed by
>> a different person.
>>
>> I'm not really fond of this approach :P
>
> It has the nice feature that many people can create merges, and if they
> create exactly the same merge (from exactly the same parents) then only
> one revision results (just with multiple certs decorating it).

Yeah, I'm aware of the reasoning, but IMO it's too much complexity for
almost no gain. It's much easier to just 'git fetch' and synchronize
the changes.

Anyway, good to know they updated the ancestry handling :)

-- 
Felipe Contreras

Re: Which VCS besides git?

[Ben Walton]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Excerpts from Felipe Contreras's message of Wed Mar 03 06:58:41 -0500 2010:

> change. Instead, they ensure security by signing every piece of data
> about a commit (commit date, author, commit message). So it's possible
> to have multiple commit dates, authors, messages, etc. each signed by
> a different person.

As a side point...

This is also a lot of extra overhead for people to get up and going.
The git approach of guaranteeing integrity by signing tags only is
much better, both because it accomplishes the same thing and because
people can actually use it without having to share keys everywhere.

[I can't get (most) people to use keys for ssh, good luck trying to
get them to do it for version control...]

-Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Which VCS besides git?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Tue, Mar 02, 2010 at 08:12:22AM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
> I don't know about Darcs, or BitKeeper, or ClearCase, or Perforce.

Darcs does not have immutable history. It uses hashes instead of integer
versions (because of being distributed), but it computes the hash like
this:

http://progetti.arstecnica.it/tailor/browser/vcpx/repository/darcs/source.py#L495

So basically the commit hash does not use the hash of the commit
contents, only the commit date/author/message/etc.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]