Re: git-svn and repository hierarchy?

[Josef Wolf <jw@raven.inka.de>]

On Wed, Mar 04, 2009 at 05:06:06PM -0500, Peter Harris wrote:
> On Wed, Mar 4, 2009 at 2:27 PM, Josef Wolf wrote:
> > On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:
> >>
> >> Sounds like subversion isn't properly caching your credentials, or
> >> your admin is paranoid and turned off the svn credential cache. I
> >> can't remember the last time I had to enter a password.
> >
> > What credential cache are you talking about?  I don't know of any
> > worth to be mentioned.  If you talk about "store-passwords=yes" in
> > subversion's config
> 
> Yes, that's the one.
> 
> > you might be interested to read
> > http://curl.haxx.se/docs/adv_20090303.html
> 
> Not really, since I use svn:// :-)

Doesn't help ;-)  Many applications are using curllib, and all of them
can reveal your .netrc or subversion config.  For example, zypper and
apt use curllib, AFAIR.

> > BTW: The paranoid admin is myself.   ;-)
> > BTW1: I know there's the possibility of client certificates.  But AFAIK,
> >      there's no equivalent to ssh-agent, so it's pointless.
> 
> I thought that this was already a part of svn, but it appears in the
> 1.6 (not quite final yet) release notes: "SSL client certificate
> passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,
> a Windows CryptoAPI encrypted form or in plaintext form."

Ummm, I always found it hard to find their changelog.  At least
http://svn.collab.net/viewvc/svn/trunk/CHANGES?view=markup&pathrev=36138
don't mention those features.  Do you have a pointer?

> > Within svn, the author field seems to be correct (at least, it is
> > identical to those of the commits that were done directly to svn)
> > But when the commits come back to git, it is set to
> > "jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>" with the host-part being
> > the uuid of the svn-repo.
> >
> > Any ideas how to fix that?
> 
> "git help svn" and look for "--authors-file", maybe. I don't use it
> myself, so I'm afraid I can't help with that one.

Ah, I missed that.

> > Oh, and what happens if svn's rev-properties (commit log, author, date...)
> > are changed?
> 
> Too late. git svn will ignore the change to the history, since git
> forces you to rewrite your entire history if any part changes. Cue
> standard "log messages should [not] be mutable" flamewar.
> 
> Ah, here it is... <flamebait version>: Nothing happens. git will
> correctly store your *true* log/author/date, ignoring any and all
> attempts by malicious parties to destroy useful historical
> information.
> 
> Of course, you're a paranoid admin, so you already have a
> pre-revprop-change hook in your svn server that prevents
> log/author/date changes. Right? ;-)

Well, actually it allows the changes for a very limited user group (that
is: only me 8-).  While I agree that author/date should not be changed,
I like to be able to fix silly typos in the log.  After all, we all do
typos now and then ;-)

> > In contrast, working directly against an svn repository is _very_
> > tedious.
> 
> Tell me about it. Fortunately, we have git-svn to save us from the
> default svn client. ;-)

Fortunately, the default client asks me for the password only once when
I commit something.  git-svn is different here ;-)

> (Sorry, couldn't resist pulling that one out of context)

(Me too)

> >  With a dozen commits pending, you have to enter your password
> > about 30..50 times in "git svn dcommit".
> 
> Maybe svn 1.6 will fix that for you?

I don't think the problem is svn here.  Me tends to think git uses
curllib not in the way it was meant to be used.  And git-svn should
reuse the existing connection instead of creating a new one for every
bit it is going to transport.

> >  # 2. move commits from clone to subversion
> >  #
> >  cd git-svn-repos
> >  git svn rebase
> >  git pull ../clone$clone topic-branch   # need rebase?
> 
> Yeah, a "git svn rebase -l" after this line wouldn't hurt, and is
> suggested by "git help svn".
> 
> Or even reverse those two lines, to save adding a third:
>   git pull ../clone$clone topic-branch
>   git svn rebase

With this, I get twice as much conflicts (half of them being spurious).
But the history is linear on the clones, thus reflecting the svn history
more accurately, I guess.

> Alternatively, you can avoid potential pull conflicts by using a
> temporary branch to avoid the merge you are about to throw away with
> rebase -- remember that 'pull' is short for 'fetch && merge':
> 
> git fetch ../clone$clone topic-branch:scratch
> git checkout scratch
> git rebase trunk
> git svn dcommit
> git checkout master
> git svn rebase -l # fast-forward master to where scratch is
> git branch -d scratch
> 
> ...which should result in seeing only the rebase conflict(s). And
> ought to work if cloneN's topic-branch is on a different svn branch
> from master (although you'd need to -D scratch instead of -d).

I guess you meant "git svn rebase trunk", since dcommit complains about
outdated transactions if "git rebase trunk" is used.

Overall, this looks very good, since the history is linear and I get
only spurious conflicts, which I can get rid of with "git rebase --skip".

Maybe there's room for more improvement:  Since the merge is done on a
scratch branch anyway, why not letting the clones _push_ into branches
with random names: cloneX-`uuidgen` or something.  So the clones could
do the push whenever they have net access.  The actual merge can be done
completely decoupled from the push operation.