On Mon, 2008-11-24 at 11:36 -0400, bulia byak wrote:
On Mon, Nov 24, 2008 at 11:11 AM, Maximilian Albert
Another strange thing: I downloaded a fresh checkout using svn only (not git-svn), and the revision numbers in the log jump from #19921 directly to #20226, although clearly there were other commits in between. The log entry for #20226 says something about merging a branch. Could it be that accidentally some revisions got lost in the process and that this is also what confuses git-svn? How can it be fixed?
I don't use git, but I would also like to know what was the reason for the series of touch-all-files commits that Ted did, e.g. 20232, with obscure commit comments like "merge from trunk"? What was merged with what? For me as SVN user, the inconvenience was limited to a total recompile, but it looks like git users are having worse problems than that.
The short answer:
bzr-svn did something I didn't expect and managed to remerge in all of the changes that people had made over the last few months. I checked all the diffs and there was no issue other than a few extra commits and confusing log messages.
The long answer:
So a while back, I don't remember when I had unbound my "trunk" branch from the Inkscape SVN trunk. So instead of updating I was merging from the SVN trunk into my Bazaar trunk. This didn't seem like much of an issue at the time and so while it took an extra command, I didn't bother with looking into it and continued to work along like normal.
The way that I work with Inkscape (and most other projects) is that I use Bazaar's shared repository mode. This means that I have one copy of the history no matter how many branches I make of it. So I have a trunk, then I branch that off and do a small project and then merge it back into trunk. This works really well for me as sometime I end up abandoning things and they don't get weaved together, but if I want them to I can also merge them together.
But, as you may be seeing, these two things created a perfect storm. As my trunk was no longer "trunk" effectively my sub-branches had started to become "sub-sub-branches" off of trunk. Which isn't a big deal, until I tried to merge them back into the real trunk. What bzr-svn then tried to do is recreate the sub-branch on the real trunk, and then merge the changes in. So it effectively rebuild a branch and merged onto that branch. Which is a little crazy, but since it seems to have done it correctly doesn't seem like a big deal.
Needless to say, I have rebound my trunk to the Inkscape SVN trunk so this is no longer an issue.
I imagine for git-svn users this will result in a longer download of those revisions, I would imagine that git-svn can handle this case and it just has to look further through the history than it normally would to recreate everything.
--Ted