On Aug 28, 2006, at 20:59, Andrew Webb wrote:
> Apart from the fact that it's of general interest to me when a code
> file was last modified (something that seems to get lost when you
> import the files into an SVN repository), my main use-case is that of
> copying only those files that have changed to a virtual machine, where
> I build installers. The reason for this is slow operation of the VM,
> and slow access of the VM to the network. I really have to keep the
> number of file copies down to a minimum. Now some of the files that
> get copied are DLLs and EXEs, and thus not under source code control
> in themselves. But other files are data files, and currently I rely
> on their last-modified dates to copy only those that have changed
> since a certain date. This is how I work with VSS as our source code
> control system. Of course it may be the case that the use of SVN may
> afford a different style of working that means I don't have to rely on
> last-modified dates.
You could simply check out a working copy of the project on the
virtual machine, if it has access to the network. Then just "svn up"
when you want to update to the latest version. Not only will
Subversion not re-download all files, it won't even download just the
changed files -- it'll download only the *changes* to the files, so
it's extremely efficient.
> Another use-case is receiving data files from, and sending data files
> to, people who are external to the developer team (e.g. marketing
> folks, or even clients) who don't use source code control. Although
> documents should have in-document revision histories, sometimes this
> doesn't happen with the desired accuracy. In this case last-modified
> dates on the files can prove invaluable in checking which is the most
> up-to-date copy of a document. This is why we're careful to always
> Zip-compress files, even a single file that would be considered as a
> safe email attachment: Zips maintain the last-modified dates.
In-document revision histories (change logs) are not recommended with
Subversion, for reasons explained here:
http://subversion.tigris.org/faq.html#log-in-source
As for your desire for modification dates for this reason, I'm not
sure what to suggest. Once you get going with the project, any time
you check in, the revision will have the date and time at which you
checked in. Which is just about as good as a modification date and
time, so long as you don't wait to long between modification and
checkin. And you can use the "use-commit-times" option so that, when
you check out or update, you don't get the current date and time but
the commit time. Maybe that's good enough for what you need.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 28 22:20:27 2006