Alan Jay Weiner wrote:
> Am I correct in thinking that Subversion doesn't maintain a timestamp for
> file? That when checked out ("Switch" or "Update" commands) they will be
> to either the current time or the time of the last commit? (depending on
> setting of "use-commit-times")
> (this, btw, is one thing I *don't* like about Subversion - I'd much rather
> file information stayed with the file... Although I can understand the
> reasoning... I did try changing svn:date on revisions and that worked;
> couldn't do it on individual files though - am I right in thinking there
> isn't a way to have different timestamps on files within a single
Entirely correct. The theory is that the important time is the time when the
changes are committed into the repository, not whenever the changes happened
to be made in a working copy. This makes complete sense for the primary
intended use of subversion - source code control. It would be interesting to
hear the details of why this isn't ideal for your application of subversion.
> I could simulate this by committing each file individually; that would
> revisions for each file, and I could set the svn:date for each revision to
> date that I wanted that file to be. This would create a huge number of
> revisions, but I'd get timestamps that would match my CDROM backups...
> Is there a downside to doing this? Not sure if I will - realistically,
> almost never go back more than a few revisions and this sounds like more
> than I want to do... But conceptually, this'd work, right?
> Essentially, sort all the files (within a backup) by date, commit them
> individually, and then create a tag to mark that backup's point in time.
> Then repeat for each backup in sequence...
The downside is you have a mass of revisions that would be very hard to
navigate when you *do* want to look back through them.
Also, "svn log" doesn't show you the source of copies - i.e. in "svn log
.../trunk" you don't see tags - you have to look at the tag itself, see what
revnum it originates from and correlate that with the log of trunk.
Yes, this is annoying.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jul 19 15:27:13 2004