Re: git-svn and repository hierarchy?
- From
- Josef Wolf <jw@raven.inka.de>
- Date
- Mar 5, 2009, 18:05 UTC
- Message-ID
- <20090305180529.GD11278@raven.wolf.lan>
- In-Reply-To
- <eaa105840903041406k36088763w5a70fe1d7458dfb1@mail.gmail.com>
On Wed, Mar 04, 2009 at 05:06:06PM -0500, Peter Harris wrote:
Show 17 quoted lines
> 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.
Show 8 quoted lines
> > 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?
Show 10 quoted lines
> > 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.
Show 15 quoted lines
> > 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 ;-)
Show 5 quoted lines
> > 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.
Show 12 quoted lines
> > # 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.
Show 15 quoted lines
> 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.