www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: Subversion Server Plan
Date Tue, 31 Mar 2009 11:25:44 GMT
El lun, 30-03-2009 a las 18:14 -0700, Roy T. Fielding escribió: 
> On Mar 30, 2009, at 1:39 PM, Santiago Gala wrote:
> > Subversion was sold to us (and probably to the git-svn developers) as
> > something with a feature called "atomic commits"... if git-svn commits
> > and updates what it committed later on, as sanity check (and maybe
> > because of keyword expansion or other nasty tricks that can spoil the
> > crypto hash), and the reload does not contain the commit it just  
> > did, I
> > think panicking is the only reasonable behaviour.
> Keyword expansion and "other nasty tricks" are irrelevant to the
> process of applying a sequential set of patches, so doing an update

It is not irrelevant for git, see below.

> between each commit is not only stupid but recklessly poor behavior
> for a client hitting a shared service.  This is a bug in git-svn,
> since it isn't doing what its own docs say (the update is only
> supposed to occur after all the patches are applied).

If one bit changes, the git commit changes. Those are the rules for
git-as-a-filesystem: the name of the commit is the SHA-1 of the commit.
And the commit includes the tree, and the SHA-1 of the parent(s)... So
if there is a risk that the server changes *any* bit, the commit chain
would be broken unless git-svn gets the new one "as the server sees it",
and rebases to it before committing the next one.

git gives integrity of commits, at the cost of needing to know all the
bits in every commit before doing the next one.

> I am curious what happens when someone does
>     git svn dcommit --no-rebase
> Does it still puke?

>>From the sources, it will print:

      warn "Attempting to commit more than one change while",
           "--no-rebase is enabled.\n",
           "If these changes depend on each other, re-running ",
           "without --no-rebase may be required."

I guess it will break, as pquerna said, because the mirror does not know
about the base revision for the commit, irrespective of the rebase
taking place or not.


> ....Roy

View raw message