My apologies for taking so long to answer... procrastination and playing with
Subversion and TortoiseSVN... (yeah, mostly procrastination... :)
>> 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...
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...
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.
3) "We've always done it that way" :)
None are compelling enough for me not to use Subversion going forward.
>> 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.
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've already submitted a suggestion for TortoiseSVN to make branching/tagging
more convenient/less errorprone/more the way *I* want it... :) Basically
just abstracting away from the project/trunk vs. project/tag path; TSVN would
put the correct path for "this project's tag" or "this project's branches" and
the user would check-box "making a tag" or "making a branch". If it were in
Subversion itself, then when the project is imported, it would/could be
configured to know "trunk for projectX is projectX/trunk, branches go in
projectX/branches, and tags go in projectX/tags" and then URLs could be
project-root and function based... Of course, the way it is now "just works"
which really *is* neat - but uses [meaning *me!*] make mistakes...)
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"
- Al -
--
-- Alan Weiner -- alan_at_ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 26 04:04:12 2004