Re: Details for svn test repository

[Daniel Berlin <dberlin at dberlin dot org>]

On Thu, 2005-02-10 at 17:46 +0000, Joseph S. Myers wrote:
> On Thu, 10 Feb 2005, Daniel Berlin wrote:
> 
> > I don't believe there is a current way to tell that a file's property
> > changed vs a file's content.  Though that should be easy enough to add
> > to svn if such a differentiation was wanted.
> 
> The reason I didn't notice that the svn log -v output had any indication 
> of the property change in the directory is that I expected it to mention 
> somewhere the name of the property changed, e.g. to say
> 
>    M /trunk/gcc/doc (property svn:ignore)
> 
> or similar (and likewise for properties added or removed), but I doubt an 
> imcompatible change to svn log output format is worth doing here.
> 

> > We could also request a "property changes only" version of log (plog),
> > or something, if that is what was wanted.  But it might entail
> > client/server protocol changes (which are not verboten, but require more
> > testing to make sure everything fails in a graceful way when not
> > supported), i'd have to look if that is what you wanted.
> 
> The natural user interface would seem to be allowing -N with log to report 
> just changes to a directory itself - whether properties or addition or 
> removal of the directory or any other change Subversion understands as 
> applying to directories themselves.  But I don't know whether that would 
> need a protocol change.

I can ask.

> 
> Another question - how do I view logs for a file which has been deleted, 
> possibly in a directory which has been deleted? 
>  In CVS, I can do "cvs log 
> ra.c" if the directory hasn't been deleted, or if the directory has been 
> deleted then "cvs update -d f; cvs log f/Make-lang.in".  But "svn log" 
> produces errors "Skipped 'ra.c'" or "'f' is not a working copy" and giving 
> a full svn:// path instead says "svn: File not found: revision 76596, path 
> '/trunk/gcc/ra.c'".  (I don't know if specifying a version number in which 
> that file existed would do, but needing to locate such a version number 
> first seems odd.)

The file doesn't actually exist in that revision, so it skips it :)

You want svn log <filename>@rev-that-it-exists
To find rev-that-it-exists, just do log on the parent directory to
discover when it was there, and when it wasn't.


> 
> (The most common case in which I have wanted such logs in practice is to 
> view logs of .texi files from before they moved from gcc/ to gcc/doc/ 
> (which would also be dealt with if cvs2svn could track those moves as 
> being actual file renames / copies - note gcc.texi changes in that move to 
> refer to the new file name install-old.texi so that isn't quite just a 
> case of detecting identical contents of added/removed files, manual hints 
> might be needed).)

I'm not really sure trying to add this logic into the middle of the
dumper makes sense. It would require a *lot* of work to try to work
around what we know is a failing in cvs.