{"thread":{"id":"22882","subject":"Which VCS besides git?","startedAt":"2010-03-02T14:55:37Z","lastAt":"2010-03-03T12:49:01Z","messageCount":13,"participants":["Kārlis Repsons","Shawn O. Pearce","Jakub Narebski","Ben Walton","Felipe Contreras","Bruce Stephens","Miklos Vajna"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136022","messageId":"201003021455.52483.karlis.repsons@gmail.com","threadId":"22882","inReplyTo":null,"subject":"Which VCS besides git?","fromName":"Kārlis Repsons","fromEmail":"karlis.repsons@gmail.com","sentAt":"2010-03-02T14:55:37Z","receivedAt":"2010-03-02T14:55:37Z","isPatch":false,"sender":{"key":"karlis.repsons@gmail.com","avatar":null},"body":"People,\nwhich VCS besides git provide chaining of commits with help of some \ncryptographic hash function, warning about or not allowing commits to be \ndeleted on an equivalent of pull action, so that all added pieces of data can \nbe retained securely on client side?\n"},{"id":"136024","messageId":"20100302152821.GD28997@spearce.org","threadId":"22882","inReplyTo":"201003021455.52483.karlis.repsons@gmail.com","subject":"Re: Which VCS besides git?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-03-02T15:28:21Z","receivedAt":"2010-03-02T15:28:21Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"K??rlis Repsons <karlis.repsons@gmail.com> wrote:\n> which VCS besides git provide chaining of commits with help of some \n> cryptographic hash function, warning about or not allowing commits to be \n> deleted on an equivalent of pull action, so that all added pieces of data can \n> be retained securely on client side?\n\nMost of the distributed VCS systems do this.  I know Mercurial is\nfunctionally identical to Git in this regard.  Maybe even Monotone\nand Bazaar are as well, but I'm less familiar with those.\n\n-- \nShawn.\n"},{"id":"136026","messageId":"201003021538.15276.karlis.repsons@gmail.com","threadId":"22882","inReplyTo":"20100302152821.GD28997@spearce.org","subject":"Re: Which VCS besides git?","fromName":"Kārlis Repsons","fromEmail":"karlis.repsons@gmail.com","sentAt":"2010-03-02T15:38:11Z","receivedAt":"2010-03-02T15:38:11Z","isPatch":false,"sender":{"key":"karlis.repsons@gmail.com","avatar":null},"body":"On Tuesday 02 March 2010 15:28:21 Shawn O. Pearce wrote:\n> K??rlis Repsons <karlis.repsons@gmail.com> wrote:\n> > which VCS besides git provide chaining of commits with help of some\n> > cryptographic hash function, warning about or not allowing commits to be\n> > deleted on an equivalent of pull action, so that all added pieces of data\n> > can be retained securely on client side?\n> \n> Most of the distributed VCS systems do this.  I know Mercurial is\n> functionally identical to Git in this regard.  Maybe even Monotone\n> and Bazaar are as well, but I'm less familiar with those.\nAnd svn doesn't?\n"},{"id":"136027","messageId":"20100302154128.GE28997@spearce.org","threadId":"22882","inReplyTo":"201003021538.15276.karlis.repsons@gmail.com","subject":"Re: Which VCS besides git?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-03-02T15:41:28Z","receivedAt":"2010-03-02T15:41:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"K??rlis Repsons <karlis.repsons@gmail.com> wrote:\n> On Tuesday 02 March 2010 15:28:21 Shawn O. Pearce wrote:\n> > K??rlis Repsons <karlis.repsons@gmail.com> wrote:\n> > > which VCS besides git provide chaining of commits with help of some\n> > > cryptographic hash function, warning about or not allowing commits to be\n> > > deleted on an equivalent of pull action, so that all added pieces of data\n> > > can be retained securely on client side?\n> > \n> > Most of the distributed VCS systems do this.  I know Mercurial is\n> > functionally identical to Git in this regard.  Maybe even Monotone\n> > and Bazaar are as well, but I'm less familiar with those.\n> \n> And svn doesn't?\n\nI don't know about SVN.  I only used it for a few months between\nCVS and BitKeeper.  After that, I jumped pretty fast into Git and\ndidn't care about how Subversion works internally.\n\nYou might want to ask on the SVN mailing list rather than the Git\nmailing list about SVN specific details...\n\n-- \nShawn.\n"},{"id":"136028","messageId":"m3y6ialn3z.fsf@localhost.localdomain","threadId":"22882","inReplyTo":"201003021455.52483.karlis.repsons@gmail.com","subject":"Re: Which VCS besides git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-03-02T16:12:22Z","receivedAt":"2010-03-02T16:12:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kārlis Repsons <karlis.repsons@gmail.com> writes:\n\n> which VCS besides git provide chaining of commits with help of some \n> cryptographic hash function, warning about or not allowing commits to be \n> deleted on an equivalent of pull action, so that all added pieces of data can \n> be retained securely on client side?\n\nCould you rephrase your request in more clear way?\n\nIf you want to know which VCS beside Git use cryptographic hash\nfunction over commit info and commit parentage as commit id, then both\nMonotone (from which Git borrowed this idea) and Mercurial use it.\n\nBazaar, if I understand it correctly, and from what I remember, uses\nsome UUID which includes commit digest as a commit identifier, but I\ndon't know if Bazaar have immutable history.\n\nIn Subversion you can change svn:log (or something like that)\nproperty, i.e. change commit message, after the fact; I don't think\nthere is any check for that.  CVS doesn't support changesets, so it is\nout of question.\n\nI don't know about Darcs, or BitKeeper, or ClearCase, or Perforce.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"136029","messageId":"201003021622.22196.karlis.repsons@gmail.com","threadId":"22882","inReplyTo":"m3y6ialn3z.fsf@localhost.localdomain","subject":"Re: Which VCS besides git?","fromName":"Kārlis Repsons","fromEmail":"karlis.repsons@gmail.com","sentAt":"2010-03-02T16:22:16Z","receivedAt":"2010-03-02T16:22:16Z","isPatch":false,"sender":{"key":"karlis.repsons@gmail.com","avatar":null},"body":"On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:\n> Kārlis Repsons <karlis.repsons@gmail.com> writes:\n> > which VCS besides git provide chaining of commits with help of some\n> > cryptographic hash function, warning about or not allowing commits to be\n> > deleted on an equivalent of pull action, so that all added pieces of data\n> > can be retained securely on client side?\n> \n> Could you rephrase your request in more clear way?\n> \n> Bazaar, if I understand it correctly, and from what I remember, uses\n> some UUID which includes commit digest as a commit identifier, but I\n> don't know if Bazaar have immutable history.\nOn top of what you wrote already, I'd like to know which VCS have immutable \nhistory, which can all be stored (say, gradually accumulated) on clientside? I \nhope, that explained the idea...\n"},{"id":"136030","messageId":"1267547722-sup-9250@pinkfloyd.chass.utoronto.ca","threadId":"22882","inReplyTo":"201003021622.22196.karlis.repsons@gmail.com","subject":"Re: Which VCS besides git?","fromName":"Ben Walton","fromEmail":"bwalton@artsci.utoronto.ca","sentAt":"2010-03-02T16:38:30Z","receivedAt":"2010-03-02T16:38:30Z","isPatch":false,"sender":{"key":"bdwalton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/396061?v=4"},"body":"Excerpts from Kārlis Repsons's message of Tue Mar 02 11:22:16 -0500 2010:\n\n> On top of what you wrote already, I'd like to know which VCS have\n> immutable history, which can all be stored (say, gradually\n> accumulated) on clientside? I hope, that explained the idea...\n\nMonotone does have immutable history (unless you munge the db by hand)\nand is distributed (full history in each repo, good merging, etc).\n\nI enjoyed mtn for a few years before getting hooked on git.  I've\nfound git much more pleasurable (and powerful) to use though.\n\nHTH.\n-Ben\n"},{"id":"136055","messageId":"201003030241.16959.jnareb@gmail.com","threadId":"22882","inReplyTo":"201003021622.22196.karlis.repsons@gmail.com","subject":"Re: Which VCS besides git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-03-03T01:41:16Z","receivedAt":"2010-03-03T01:41:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kārlis Repsons wrote:\n> On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:\n> > Kārlis Repsons <karlis.repsons@gmail.com> writes:\n\n> > > which VCS besides git provide chaining of commits with help of some\n> > > cryptographic hash function, warning about or not allowing commits to be\n> > > deleted on an equivalent of pull action, so that all added pieces of data\n> > > can be retained securely on client side?\n> > \n> > Could you rephrase your request in more clear way?\n>\n> On top of what you wrote already, I'd like to know which VCS have immutable \n> history, which can all be stored (say, gradually accumulated) on clientside? I \n> hope, that explained the idea...\n\nAs I wrote, all VCS which use cryptographic hash function (digest) for\ncommit identifier have immutable history.\n\nAll distributed VCS (DVCS) store whole[*] history with checkout.  There\nisn't (beside _social_ reasons) any distinction between different repos:\nthere is no client - server model (so no \"clientside\"), but rather peer\n2 peer model.  See http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model\n(from OSS ones I'd say Git, Mercurial, Bazaar, Darcs, Monotone count).\n\n\n[*] well, with possibly some exceptions, like shallow clone, or selecting\n    branches to clone.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"136070","messageId":"94a0d4531003030358q276a8e9bue086a8ec06aba395@mail.gmail.com","threadId":"22882","inReplyTo":"201003030241.16959.jnareb@gmail.com","subject":"Re: Which VCS besides git?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-03-03T11:58:41Z","receivedAt":"2010-03-03T11:58:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Mar 3, 2010 at 3:41 AM, Jakub Narebski <jnareb@gmail.com> wrote:\n> Kārlis Repsons wrote:\n>> On Tuesday 02 March 2010 16:12:22 Jakub Narebski wrote:\n>> > Kārlis Repsons <karlis.repsons@gmail.com> writes:\n>\n>> > > which VCS besides git provide chaining of commits with help of some\n>> > > cryptographic hash function, warning about or not allowing commits to be\n>> > > deleted on an equivalent of pull action, so that all added pieces of data\n>> > > can be retained securely on client side?\n>> >\n>> > Could you rephrase your request in more clear way?\n>>\n>> On top of what you wrote already, I'd like to know which VCS have immutable\n>> history, which can all be stored (say, gradually accumulated) on clientside? I\n>> hope, that explained the idea...\n>\n> As I wrote, all VCS which use cryptographic hash function (digest) for\n> commit identifier have immutable history.\n\nThat's not exactly correct. Monotone works very differently; a\nrevision doesn't include the ancestry, that's handled in a separate\nstructure, so the revision hash doesn't tell you anything about the\nancestry. In fact, a revision doesn't contain anything, the data is\nhandled by \"certs\", and certs can be added later.\n\nFor example, it's possible to clone a repository and then add a second\ncommit message to a bunch of revisions. The revision hash doesn't\nchange. Instead, they ensure security by signing every piece of data\nabout a commit (commit date, author, commit message). So it's possible\nto have multiple commit dates, authors, messages, etc. each signed by\na different person.\n\nI'm not really fond of this approach :P\n\n-- \nFelipe Contreras\n"},{"id":"136072","messageId":"80fx4hbo4f.fsf@tiny.isode.net","threadId":"22882","inReplyTo":"94a0d4531003030358q276a8e9bue086a8ec06aba395@mail.gmail.com","subject":"Re: Which VCS besides git?","fromName":"Bruce Stephens","fromEmail":"bruce.stephens@isode.com","sentAt":"2010-03-03T12:12:16Z","receivedAt":"2010-03-03T12:12:16Z","isPatch":false,"sender":{"key":"bruce.stephens@isode.com","avatar":null},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n[...]\n\n> That's not exactly correct. Monotone works very differently; a\n> revision doesn't include the ancestry, that's handled in a separate\n> structure, so the revision hash doesn't tell you anything about the\n> ancestry.\n\nNot so.  Long ago that was the case (ancestry was via certs), but that's\nnot been the case for a long time.  There are (in retrospect) obvious\nadvantages in including the ancestry in the hash.\n\n> In fact, a revision doesn't contain anything, the data is handled by\n> \"certs\", and certs can be added later.\n\nRevisions lack date, author, branch, commit message, but include\nancestry and the actual changes (which files/directories have changed\nand how).\n\n> For example, it's possible to clone a repository and then add a second\n> commit message to a bunch of revisions. The revision hash doesn't\n> change. Instead, they ensure security by signing every piece of data\n> about a commit (commit date, author, commit message). So it's possible\n> to have multiple commit dates, authors, messages, etc. each signed by\n> a different person.\n>\n> I'm not really fond of this approach :P\n\nIt has the nice feature that many people can create merges, and if they\ncreate exactly the same merge (from exactly the same parents) then only\none revision results (just with multiple certs decorating it).\n\n(Monotone has changed since I last used it but I think the above is\nstill true.  There's been discussion about larger certs (rather than\nhaving separate certs for branch, date, author, message, to have just\none covering the usual combination) AFAIK that hasn't happened yet.)\n"},{"id":"136074","messageId":"94a0d4531003030431t3ce62d0g9b8458fe5a8a54ef@mail.gmail.com","threadId":"22882","inReplyTo":"80fx4hbo4f.fsf@tiny.isode.net","subject":"Re: Which VCS besides git?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-03-03T12:31:05Z","receivedAt":"2010-03-03T12:31:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Mar 3, 2010 at 2:12 PM, Bruce Stephens <bruce.stephens@isode.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n> [...]\n>\n>> That's not exactly correct. Monotone works very differently; a\n>> revision doesn't include the ancestry, that's handled in a separate\n>> structure, so the revision hash doesn't tell you anything about the\n>> ancestry.\n>\n> Not so.  Long ago that was the case (ancestry was via certs), but that's\n> not been the case for a long time.  There are (in retrospect) obvious\n> advantages in including the ancestry in the hash.\n\nAh, I looked quickly ad one db and still saw 'revision_ancestry' being\nused. I guess they decided to keep the information redundant.\n\n>> In fact, a revision doesn't contain anything, the data is handled by\n>> \"certs\", and certs can be added later.\n>\n> Revisions lack date, author, branch, commit message, but include\n> ancestry and the actual changes (which files/directories have changed\n> and how).\n>\n>> For example, it's possible to clone a repository and then add a second\n>> commit message to a bunch of revisions. The revision hash doesn't\n>> change. Instead, they ensure security by signing every piece of data\n>> about a commit (commit date, author, commit message). So it's possible\n>> to have multiple commit dates, authors, messages, etc. each signed by\n>> a different person.\n>>\n>> I'm not really fond of this approach :P\n>\n> It has the nice feature that many people can create merges, and if they\n> create exactly the same merge (from exactly the same parents) then only\n> one revision results (just with multiple certs decorating it).\n\nYeah, I'm aware of the reasoning, but IMO it's too much complexity for\nalmost no gain. It's much easier to just 'git fetch' and synchronize\nthe changes.\n\nAnyway, good to know they updated the ancestry handling :)\n\n-- \nFelipe Contreras\n"},{"id":"136076","messageId":"1267620460-sup-2115@pinkfloyd.chass.utoronto.ca","threadId":"22882","inReplyTo":"94a0d4531003030358q276a8e9bue086a8ec06aba395@mail.gmail.com","subject":"Re: Which VCS besides git?","fromName":"Ben Walton","fromEmail":"bwalton@artsci.utoronto.ca","sentAt":"2010-03-03T12:48:39Z","receivedAt":"2010-03-03T12:48:39Z","isPatch":false,"sender":{"key":"bdwalton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/396061?v=4"},"body":"Excerpts from Felipe Contreras's message of Wed Mar 03 06:58:41 -0500 2010:\n\n> change. Instead, they ensure security by signing every piece of data\n> about a commit (commit date, author, commit message). So it's possible\n> to have multiple commit dates, authors, messages, etc. each signed by\n> a different person.\n\nAs a side point...\n\nThis is also a lot of extra overhead for people to get up and going.\nThe git approach of guaranteeing integrity by signing tags only is\nmuch better, both because it accomplishes the same thing and because\npeople can actually use it without having to share keys everywhere.\n\n[I can't get (most) people to use keys for ssh, good luck trying to\nget them to do it for version control...]\n\n-Ben\n"},{"id":"136075","messageId":"20100303124901.GM27414@genesis.frugalware.org","threadId":"22882","inReplyTo":"m3y6ialn3z.fsf@localhost.localdomain","subject":"Re: Which VCS besides git?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2010-03-03T12:49:01Z","receivedAt":"2010-03-03T12:49:01Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Mar 02, 2010 at 08:12:22AM -0800, Jakub Narebski <jnareb@gmail.com> wrote:\n> I don't know about Darcs, or BitKeeper, or ClearCase, or Perforce.\n\nDarcs does not have immutable history. It uses hashes instead of integer\nversions (because of being distributed), but it computes the hash like\nthis:\n\nhttp://progetti.arstecnica.it/tailor/browser/vcpx/repository/darcs/source.py#L495\n\nSo basically the commit hash does not use the hash of the commit\ncontents, only the commit date/author/message/etc.\n"}]}