[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proper log format for renames

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-06-28 22:05:18 CEST

Blair Zajac <blair@orcaware.com> writes:
> The HACKING document doesn't have a standard way to log file
> and directory renames. Should it list the old or first name
> after the *?

Generally we seem to list the new name first, then say the old name
was renamed from it. Here is an example taken from revision 2208:

   * swig/swigutil_py.c: renamed from swig/swigutil.c
   * swig/swigutil_py.h: renamed from swig/swigutil.h
   
Roughly the same method is used for functions as for files. For
example:

   * foo.c (walk_tree): Replaces crawl_tree. Minimize db lookups to
     improve speed.

When it's complex, we've been a little more creative. For example,
here's a portion of 2059's log message:

   * subversion/libsvn_client/checkout.c
     (parse_externals_description, handle_externals_description,
     process_externals): Moved and renamed from here...
   
   * subversion/libsvn_client/externals.c: New file.
     (svn_client__parse_externals_description,
     checkout_externals_description, svn_client__checkout_externals):
     ...to here, respectively.

When there are a lot of renames in one commit, the format may be
slightly different, but it's still new-name-first order. See revision
807 for an example.

I guess svn_load_dirs is only going to automate the file case, so only
the first part of of the above is relevant to your question :-).

> Since this is going into the svn_load_dirs script, I'd like to
> know the "right" way to do this. Here's an example log message
> of what I have currently:
>
> To prepare to load orca-0.15 into trunk/orca, perform some renames.
>
> * trunk/orca/orca/Makefile: rename to trunk/orca/docs/Makefile.in.
> * trunk/orca/orca/orca: rename to trunk/orca/src/orca.pl.
> * trunk/orca/orca/sample_configs: rename to trunk/orca/lib.

Okay; looks like this is the opposite of current practice.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 28 22:14:03 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.