Hello,
I have set up a repository hierarchy like this:
subversion-repos
|
git-svn-repos
/ | \
clone1 clone2 clone3
subversion-repos is an existing repository that can not be converted to
git.
git-svn-clone is meant as an intermediate "synchronization" repository.
I never commit directly to this repos. Its only intention is to
synchronize the clones to each other and against subversion-repos.
git-svn-clone was created by
git svn init --stdlayout $svn_url git-svn-repos
(cd git-svn-repos && git svn fetch)
cloneX are ordinary git clones of git-svn-repos for the day-by-day work.
They were created by
git clone git-svn-repos cloneX
I can successfully work on the clones. To synchronize with git-svn-clone,
I do
git stash
git pull
git push origin
git stash apply
git stash clear
And here is my first problem: every time I push to git-svn-repos, its
working tree gets out of sync, because pushing don't update the tree.
So every time I push, "git status" shows me local modifications which
are actually outdated files. I thought I could use a bare repository
to avoid this problem, but git-svn refuses to work on a bare repos.
So here's my first question: Any ideas how to get around this?
Once git-svn-repos is cleaned up, I want it to synchronize against
subversion-repos. Thus I do
git svn rebase
git svn dcommit
This works most of the time. Sometimes, I get error messages
like this from rebase:
Applying Fix logging of IP-Addresses when reading access list.
error: patch failed: upnp/websrv:528
error: upnp/websrv: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
I've never seen any damage after this error message, and the last line
suggests that this is only some informative warning.
But now here's the real catch: this time I got following error
message from "git svn rebase":
Auto-merged server/misc.c
CONFLICT (content): Merge conflict in server/misc.c
Failed to merge in the changes.
Patch failed at 0005.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
Unfortunately, none of the three suggested commands help.
Investigation reveals that the conflict was caused by two independent
commits to one of the clones. That is: both commits were on the same
clone and no commits were done to the other clones in the mean time.
The commits just happen to touch neighboring lines.
Those two commits have managed to go all the way up from cloneA through
git-svn-repos to subversion-repos without any problem. Only on the way
back from subversion-repos to git-svn-repos, they create the conflict.
Any ideas how to clean up from the situation? And how to avoid this
problem in the future?
--
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
