Subversion migration issue

[Ross Golder <ross golder org>]

Tim Janik has discovered an issue with subversion whereby it is 
difficult to obtain the log message of a deleted files when searching by 
a range of revisions:

> i just ran into another SVN issue, this time i consider it pretty grave.
> around revision r3956 i added bseiirfilter.c to the beast SVN and deleted
> it at some point later. i have extremely hard times finding out the exact
> revisions i added and deleted/moved the file, because svn log 
<delted-file>
> is essentially broken. this is apparently a known issue:
>
>     http://svn.haxx.se/dev/archive-2003-07/1149.shtml
>
> however, the "workaround" described therein doesn't really function for
> getting the logs for a range of revisions (using debian stable svn here):
>
> tjlocal birgrave:bash</opt/src/beast/bse>$ svn --version
> svn, version 1.1.4 (r13838)
>    compiled May 13 2005, 06:29:47
> tjlocal birgrave:bash</opt/src/beast/bse>$ svn log -v -r3956
> svn+ssh://timj svn gnome org/svn/beast/trunk/bse/bseiirfilter.c
> ------------------------------------------------------------------------
> r3956 | timj | 2006-10-12 01:41:13 +0200 (Thu, 12 Oct 2006) | 9 lines
> Changed paths:
>    M /trunk/bse/ChangeLog
>    A /trunk/bse/bseiirfilter.c
>    A /trunk/bse/bseiirfilter.h
>
> Thu Oct 12 01:38:39 2006  Tim Janik  <timj gtk org>
>
>         * bseiirfilter.c: added concatenated source code of the ellf 
filter
>         design program by Stephen L. Moshier. program homepage is:
>           http://www.moshier.net/ellfdoc.html
>
>         * bseiirfilter.h: new empty header file.
>
>
> ------------------------------------------------------------------------
> tjlocal birgrave:bash</opt/src/beast/bse>$ svn log -v -r3956:HEAD
> svn+ssh://timj svn gnome org/svn/beast/trunk/bse/bseiirfilter.c
> svn: File not found: revision 4041, path '/trunk/bse/bseiirfilter.c'
>
> i also fail to get the revision log via the viewsvn interface, because
> it either displays specific revisions or HEAD without deleted files.
>
> i know that other projects (gtk+, gimp) also have lots of deleted/moved
> files,
> and i'd rather not lose information about revisions/logs for those.
> so unless svn at least has the basics right (in terms of being on par
> with CVS
> wrg functionality), any further migration attempts should be halted i
> think.
>

I replied:

>> What are you trying to do? It's not ideal, but I was able to use the
>> workaround to find the revision (and message) of the deletion:
>>
>> svn log -v http://svn.gnome.org/svn/beast/trunk | less
>
> yes, you can find *one* revision with the work around. that's rather
> pointless though, the real value in cvs/svn log is to get *all* log
> entries for a file, and that doesn't work for deleted files.
> so i have almost no way to e.g. spot the next or last change made to
> a deleted file. it's history may be there somwhere but it's inaccesible.

>> It doesn't seem to be losing any data as such, it's just not as easy as
>> it should be to find :)
>
> i'm not claiming the data is technically lost. the logs being unaccsible
> does render this information lost from a user perspective though, and as
> e.g. Gtk+ maintainer i would find that unaccaptable.
>

>> I'm not sure what to do about this. It's annoying, but I don't
>> personally feel that this problem is a show-stopper. The logs can be
>> found, although it takes a bit of frigging around. Also, I think it's an
>> annoyance that will eventually be fixed in the subversion
>> client/protocol once it trips enough people up. AFAICS, this would trip
>> people up so rarely that the other general benefits of SVN vs CVS
>> outweigh it as an issue, iyswim. Another way to put it might be that
>> 'other large projects didn't consider this problem enough to prevent
>> them from moving to subversion'. But that's just my opinion.
>>
>> So are you absolutely sure that you consider this problem to be serious
>> show-stopper? Obviously, I would not be happy to go any further forward
>> with attempts to migrate GNOME to subversion if I don't at least have
>> the backing of the Gtk+ maintainers :) If that's the case, it stops
>> here.
>
> simply raise this topic on gnome-hackers and find out about the community
> feedback on the issue. that'll get you the sharp cut answer you're 
looking
> for. either others are feeling as strongly about it as i do, so you can
> point to this thread in your reasonings for a failed migration, or 
you get
> the backing to continue with the migration despite this problem.
>
> as a gtk maintainer, yes i consider this pretty bad data loss, but would
> certainly go along with consensus built up on gnome-hackers, respectively
> raise my concerns there.
>

So, if you've kept up this far, what are your thoughts, you great and 
wise GNOME hackers you?

--
Ross