Alan Jay Weiner wrote:
> My apologies for taking so long to answer... procrastination and playing
> with Subversion and TortoiseSVN... (yeah, mostly procrastination... :)
Ahh, procratination. A process I am very familiar with :-)
>>> Am I correct in thinking that Subversion doesn't maintain a timestamp
for
>>> each file?
> (snip)
>
>> 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.
>
> Mostly it's the way I've worked for years - file timestamps are
meaningful...
>
> I don't mind changing my mindset (well, ok, I'm rigid and ornery, but at
least
> for the way Subversion works with timestamps I can change... :)
> Although I wouldn't be surprised if other people don't like it either...
>
> The examples I can think of are:
>
> 1) Sometimes multiple developers will need to compare files - often it's
> "what's the timestamp on foo.c..." - as far as I can see it's just as
easy
> to say "what's the version number on foo.c..." - and with TSVN's ability
to
> show the version in Windows Explorer, this seems a minor issue to me...
Right! And it's easier to remember a revnum, than to remember all the
elements of a date&time.
Also, one revnum identifies all the files in a multi-file commit.
> 2) A bigger issue would be directory-comparison utilities - if the size
and
> timestamp are the same, the files (probably) are also. When working with
> lots of files, it saves comparing the contents...
Interesting... in what scenarios do you compare? Note that "svn diff" is
optimized along those lines.
> If Subversion's set to "use last commit date" when files are
> checked-out/exported, then such utilities will still work right with any
files
> from Subversion; e.g., comparing "this" work directory with "that" work
> directory...
> But comparing to an older backup would require comparing contents.
Please, be aware the "use-commit-times" essentially breaks make and similar
utilities.
There is a reason why its not on by default.
>>> I could simulate this by committing each file individually; that would
>>> (snip)
>
>> 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 emulate what I've done in the past that'd be fine - trunk would always
be
> most-recent, and tags are the equivalent of my daily/milestone backups -
so
> (starting from an up-to-date working copy; i.e., matches the trunk) I'd
make
> my changes, then commit each file I changed, then tag the mess. *Not*
worth
> it (unless it were automated) for future work, but it'd keep my CDROM
backups
> and their corresponding files in the repository with matching timestamps.
Hmm, seems a lot of work, and is essentially fighting against subversion.
I have an alternate suggestion:
1 old commit == 1 svn commit, but set a property on files to record their
actual old timestamp. The property won't mean anything special to
subversion, of course, but the information will be preserved, and it should
be easy to write a script to recurse over a WC, doing "svn propget; touch"
if ever necessary.
> Branches and tags are one of the things I really *don't* like about
> Subversion.. Conceptually, I like the elegance of a tag being just a
branch.
> But I have already created a tag in the trunk (oops!) and I just see
myself
> making such stupid mistakes...
I hated subversion's tags too when I first read about them. I'm quite
comfortable with them now, except that there is no good way to tag only
subtrees of a project.
> The biggest problem I've had is "this is how I've done it / want to do it"
and
> Subversion does things differently... I've turned into such a
curmudgeon....
> :)
>
> Overall I like Subversion a lot, and I expect that as more use it, it will
> just get better and better. And the more I use it the more the way it
works
> will be "the way *I* work"
:-)
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 26 10:34:36 2004