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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
