GNOME Bugzilla – Bug 384363
Difficulty finding commit log for deleted files in a range
Last modified: 2011-03-22 10:03:36 UTC
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. >
Really, this needs chasing upstream with the subversion devs. If they're not going to fix it, we should probably close this ticket and make do with the workaround. I've raised the subject on #svn, and I might send the link to their dev's mailing list too.
(In reply to comment #1) [...] > we should probably close this ticket and make do with the > workaround. Ross, i'm not sure you realize this... there only is a workaround if you know a particular revision in advance. if you however use svn log to *find out* about the unknown revisions of a deleted file (e.g. to find the last used version of it for recovery), the workaround does NOT work. i.e. there is no workaround for using svn log to find a particular revision of deleted files which essentially results in deleted files being unaccesible. that's the issue i consider so grave.
From #svn: (16:43:43) Tracy_P: Add a file, make changes, delete the file. a few revisions later, look for that file. It is not found because if a file is marked as deleted it does show in the log looking for that specific file. (16:44:00) Tracy_P: does not show (16:44:24) Tracy_P: If you know the name, should it show all history for the file? (16:44:35) ninja: yep, that sounds right (16:45:17) Tracy_P: Sounds like when limiting the search to a specific file it should show, but if a wildcard is included it should not show. (16:45:42) Tracy_P: or an additional flag to add deleted files in the output (16:45:52) ninja: it should show all the history regardless, imho (16:46:28) Tracy_P: I can understand not wanting to see deleted files in the history. (16:46:57) Tracy_P: It makes the history bloated with information this isn't neccessary for most. (16:47:25) Tracy_P: When searching for that specific file, I see where a flag could be useful (16:47:41) ninja: i don't know - i think if someone asks for history, they should get to know about removed files :)
(Hi, I'm one of svn's original designers/developers, and co-author of the svnbook.) If Tim wants to find out "hey, in what revision was /trunk/bse/bseiirfilter.c deleted?", the normal way to do that is not to run 'svn log -v' on the file itself, but on the *parent* directory. Think of addition and deletion as operations on the parent directory. Something like: 'svn log -v bse -rHEAD:3956 > foo', then grep foo for "D bseiirfilter.c". It's all part of shifting the mindset away from CVS -- which is all about the history of individual files -- to Subversion -- which is about tracking the history of trees. In Subversion, 'svn log' takes a single object as an argument, either a file or a directory. If you ask for the history of 'bseiirfilter.c', and that object doesn't exist anymore (either in the working copy or repository HEAD), the natural reaction is "huh? what object?" If you ask for the history of the parent directory, you'll see every change ever made within that directory, including additions/deletions. This has never been considered a real bug by Subversion's developers, just a different way of thinking. The number of people who have been confused by it (over the last 6 years) has been pretty tiny... probably since the use-case is fairly rare, and the "recommended way" of discovering the deletion isn't that complex.
Here's the discussion thread of this issue from over on the Subversion dev list: http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=122495 Mark Phippard points out some possibly helpful info in a follow-up message.