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

On Mon, Nov 24, 2008 at 11:55 AM, Maximilian Albert

So, are you seeing any revisions between 19921 and 20226 in current SVN trunk? Strangely, in my fresh SVN checkout, svn log doesn't show me revision 20232 which you mentioned either...

Actually, I do not. So it's even worse than I thought. It seems to have caused information loss in the main SVN repository! In my bash history, I have this recent commit:

svn commit -m "patch 188849 by RM for better pencil interpolation taking into account all points" pencil-context.h pencil-context.cpp

but at

http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/penci...

there's no such comment listed.

This is very bad. We now have some recent bugs that would benefit from searching in SVN history, but the breakage makes this impossible. Please, Ted, make sure this thing never happens again. I would even suggest not using the tool which is capable of wreaking such havoc (I'm pretty sure plain SVN client cannot ever delete revisions from the repository!)