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?
Shawn O. PearceRe: Which VCS besides git?
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?
On Tuesday 02 March 2010 15:28:21 Shawn O. Pearce wrote:
Show 9 quoted lines
> 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?
Shawn O. PearceRe: Which VCS besides git?
K??rlis Repsons <karlis.repsons@gmail.com> wrote:
Show 12 quoted lines
> 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.
Jakub NarebskiRe: Which VCS besides git?
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?
On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:
Show 11 quoted lines
> 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...
Ben WaltonRe: Which VCS besides git?
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
Jakub NarebskiRe: Which VCS besides git?
Kārlis Repsons wrote:
> On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote: > > Kārlis Repsons <karlis.repsons@gmail.com> writes:
Show 10 quoted lines
> > > 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
Felipe ContrerasRe: Which VCS besides git?
On Wed, Mar 3, 2010 at 3:41 AM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 17 quoted lines
> 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?
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).
Show 8 quoted lines
> 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.)
Felipe ContrerasRe: Which VCS besides git?
On Wed, Mar 3, 2010 at 2:12 PM, Bruce Stephens <bruce.stephens@isode.com> wrote:
Show 12 quoted lines
> 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.
Show 19 quoted lines
>> 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
Ben WaltonRe: Which VCS besides git?
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
Miklos VajnaRe: Which VCS besides git?
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.