lsuvkne@onemodel.org wrote:
> We'd like to write a temporary wrapper around 'svn rename' and 'svn
> merge' which would essentially do the following:
> 1) the rename command would, in addition to what rename normally does,
> put a string in the properties (or somewhere) on both the old and new
> file, indicating that they were involved in a rename operation, the
> to/from relative paths & filenames, the branch URL (shared portion of
> to/from), the developer's name (or username), and the date/time. (We
> might also save this information off to an external log file somewhere
> for reference in case a human wants to know later for some reason.)
FWIW, I thought about using a property during rename operations a while
ago, but for other reasons. If you have, say, svn:filename=path/file you
can implement the client part so that:
1. A rename can be done immediately in the WC.
or
2. A rename can be made pending by only changing the property,
effectuated later when committing, or when executing the rename onto the WC.
With the rename in the property, you get:
1. Rev diffs (patches) containing the renames. Existing tools can be
used for reviews etc.
2. Patches/merges that are possible to apply to a WC, using existing tools.
For example, assume your college has a WC containing the file
/trunc/foo/bar.c and renames the file to /trunc/foo-lib/bar2.c. College
commits changes.
You are sitting on WC .../work-foo containing /branches/myfoo/.
When you merge your college's work into your WC, bar.c can not be
immediately renamed, because the foo-lib isn't in your WC, or (if
the path is taken unadjusted) your bar.c would end up in the trunc.
With the rename pending in the property, you can alter it to fit your
needs or even revert it entirely.
/Micke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 27 21:27:11 2007