Re: git-svn and repository hierarchy?

On Tue, Mar 3, 2009 at 5:36 PM, Josef Wolf wrote:

I'd rather not let every clone talk to subversion for several reasons.
One of them is that it is very inconvenient (e.g. the password has to
be entered several times for every commit).

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.

Of course, git-svn-repo can't cache credentials, since it has to
impersonate different users. You are impersonating different users so
that the svn author field is correct, aren't you? But that shouldn't
be a problem for userN working on cloneN.

 After all, the whole point
for having git-svn-repos is for the clone to avoid working directly
against the subversion repos.  If every clone works against subversion
anyway, I can get rid of git-svn-repos as well.

From my perspective, the main advantage of git-svn-repos is the inital
clone. Subversion is way too slow to clone an entire project's history
(days, vs minutes for git). Subsequent 'git pull --rebase's are faster
than 'git svn rebase's, too, although not by the same ratio (except
for large subtree moves, which really are that much faster).

On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:

quoted

Also, this line says "rebase my changes onto those of ../clone$clone",
which isn't what you want. It will end up rebasing svn commits that
the client didn't have on top of the client's commits, and will break
git-svn's index. Don't use --rebase here.

Hmm, I must have misunderstood Michael, then.  Wasn't he suggesting
to rebase here?  Here's the citation:

|>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,
|
|That's the problem. This creates a merge after which you 1-2-3-4 and
|1-2'-3'-4' plus the merge of 4 and 4'.
|
|Instead, use git pull --rebase here. You don't want merges in the branch
|from which you dcommit.

I think he meant to say "git pull ../cloneN && git rebase trunk".

quoted

quoted

 # Although we have resolved the conflict, spurious conflicts are
 # propagated to the clones

...and this is because you had clones all merge from each other (via
git-svn-repos) *before* the changes were in svn.

Does that mean that the conflicts would disappear if I do
git-svn-rebase + git-svn-dcommit after every pull from a clone?

Well, 'disappear' is a strong word. "cloneX" has to be willing to
reset to your branch if you have resolved any conflicts on behalf of
cloneX. But the other cloneNs should not see those conflicts, at
least.

Not to mention that it's not outside the realm of possibility that
various cloneNs may be working with each other without involving you.

Plus, there is a small window where clones may be pulling from each
other, and will have to resolve the same conflicts you resolve during
your "git svn dcommit". I'm sure you've heard the saying "Every
computer science problem can be solved by adding a level of
indirection." You could add a git-svn-stage that pulls from cloneN and
does the dcommit (and then pushes to git-svn-repos, or lets
git-svn-repos do its own "git svn fetch"), leaving git-svn-repos clean
for cloneN to pull from...

Peter Harris