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:// :-) > 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." > 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. Personally, I don't mind user@uuid. Plus, user@uuid is so obviously different from git's standard format that it is immediately obvious to me which commits are in svn, and which aren't, when running gitk. > 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? ;-) > 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. ;-) (Sorry, couldn't resist pulling that one out of context) > 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 think he meant to say "git pull ../cloneN && git rebase trunk". > > Did you mean "git pull ../cloneN && git rebase master"? There's no > trunk in git, AFAIK? If a local branch isn't found, git will automatically look in remotes, so it will use remotes/trunk (the svn tracking branch). Modify to suit if you renamed remotes/trunk, of course. "git branch -r" to see the remote branches git-svn has set up for you. I'm pretty sure I didn't mean to suggest a no-op. Assuming you git pull'd into master, "git rebase master" will be a no-op. rebase "all commits in (current branch) that aren't in master" -> set operation (master - master = empty set) -> rebase (empty set) -> done. > # 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 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). Peter Harris -- 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
