Hi Sam,
Thanks for your reply. I'm currently on the road so may be a littleslow to respond. Please bear with me.
Sam Vilain wrote:>> When using an svk mirror repository as the source for git-svn,>> find-rev and rebase don't work.>>>> find-rev takes a while, while it traverses and processes commit logs>> for the branch, and ultimately fails with the error message: "Unable>> to determine upstream SVN information from git-svn history". This>> happens because find-rev doesn't relate information in the commit>> messages to the internal svm-source revision maps.>>>> Similarly, rebase is faster but still exits with the message "Unable>> to determine upstream SVN information from working tree history".>>>> The attached patch fixes a couple of underlying issues to get at least>> these two commands working. AFAICT it still works well with plain svn>> repositories.>>>> Can this be merged upstream? Any comments are welcome.>> Can you give an approximate series of commands that led to this not> working? Just to clarify what happened. Ideally, it would be a test> case; see if you can add it to the existing SVM test case. In fact this> might be a regression compared to the original support, due to lack of> tests - in which case it would be good to fix this "for good".
I haven't tried the test cases yet, but will look into it. Perhapsthat can also hammer out other places where svm-mirror support isincomplete.
In the meantime, reproducing the 2 issues my patch is supposed to fixis rather straightforward, but there could be something that I missed,so here goes:
# Preparation, skipped informational messages. $ git init $ git svn init --use-svm-props -s file:///path/to/svk/repository/and/mirror/ # Populate repository $ git svn fetch
# And the missing functionality. $ git svn rebase Unable to determine upstream SVN information from working tree history
$ git svn find-rev r5 Unable to determine upstream SVN information from HEAD history
And trying out the test case I just noticed an issue with my previouspatch, with misplaced // -- somehow it didn't show up in my previoustests. I'll post an updated patch, shortly.
> Also, please try to send your patches inline if possible, or at least> try to get them to be Content-Disposition: inline, it makes review> easier for casual list subscribers.
I was worried that sending patches inlined would break the patchbecause of line lengths and such, since I'm using Gmail's webinterface. Anyway, I'll try that we'll see how that goes.
Cheers,
João��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
