Ben Collins-Sussman wrote:
> Greg M wrote:
>
>> The architects I work for often move files from one folder to
>> another, or rename existing files. Does svn detect this automatically?
>
>
> Judging by your last two mails, I think you're wishing for a set of
> features that neither CVS nor SVN possess. The only thing that these
> two version control systems do "automatically" is detect changes to
> versioned files. That's it. If you want these systems to notice
> *any* other type of change -- adds, deletes, copies, moves -- then you
> need to do it explicitly through the system. In other words, you run
> 'svn mv', not 'mv'. The same goes for 'svn add', 'svn rm', and 'svn
> cp'.
>
> Neither CVS nor SVN was designed to be perfectly "transparent" to the
> user. I personally think that you'll end up driving yourself to
> insanity trying to write scripts that "guess" what sorts of
> adds/deletes/copies/moves your users might have intended or not. It's
> a hard problem. Just bite the bullet and teach them to use the
> version control system. It's not rocket science, especially not if
> you have a GUI. If you want *truly* transparent versioning, then use
> WebDAV with the mod_dav_svn Autoversioning feature, documented in the
> WebDAV appendix of the book.
>
> If you insist on writing scripts that try to guess what the user did,
> here's the strategy I would use:
>
> * run 'svn status': unversioned files show up as '?'. Parse
> those out of the output and 'svn add' them before committing. Deleted
> files show up with '!', meaning that they're MIA. Parse those out of
> the output and 'svn rm' them before committing.
>
> * implement a hash-based algorithm that tries to find correlations
> between missing files and unversioned files. If you get match, then
> 'svn mv'.
>
> Still, I think that down this route lies madness. SVN isn't about to
> grow this feature. It's not a transparent system, nor does it ever
> plan to be.
I think you're on to something though. Rather than have the users work
with working copies though their work directory could be treated as a
vendor release snapshot and processed every night using svn_load_dirs
with some enhancement to record a per-file signature or hash for better
detection of moves. Worst case for a missed guess is that the history
of a moved file will be harder to find. It could all be done without
any special support in subversion itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 1 09:33:04 2004