On Nov 14, 2006, at 11:40, Les Mikesell wrote:
>>>> Actually I think the single rev# is one of the best features of
>>>> Having used "per-file" rev# systems, which deteriorate into
>>>> chaos, I
>>>> far prefer the Subversion approach. Plus the fact that, in
>>>> effect, a
>>>> rev# becomes a changelist.
>>> It makes sense for a 'project'. It doesn't make much sense
>>> for a collection of mostly unrelated files and it is cumbersome
>>> to put each in its own repository.
>> Why not? If you just think of revision numbers as tags, they are
>> as meaningful whether they increase sequentially or by bigger jumps.
> How is it meaningful - or useful - for a revision number to change
> when no related content changed? If you have a later version than
> mine, how do I know if it is different or not?
I think you're thinking in CVS terms, where revisions are per-file,
and it makes sense to say things like "Revision 1.2.2 of foo is newer
than revision 1.1 of foo." And now you're confused because you're
running into the situation "Revision 48 of foo is exactly the same as
revision 32 of foo." And the problem is in the way you're expressing
this. Don't say "Revision 48 of foo"; say "Foo as it appears in
revision 48 of the repository." Then hopefully you'll see how things
are in Subversion: "Foo as it appears in revision 48 of the
repository is the same as foo as it appears in revision 32 of the
The revision is simply the number of changes that have been made to
the repository. That's all. It doesn't have any more meaning than
that; don't attach any other meaning to it.
Using revision numbers as a way to see how much work has been done on
a file isn't useful anyway, neither in Subversion nor in CVS. In
either, you can add and remove a blank line 50 times and generate 100
new revisions; doesn't mean anything useful has happened to the file.
"svn log foo" shows you the revisions of the repository in which foo
changed, and (if you've written good log messages), what changed and
why. "svn diff -rA:B foo" shows you exactly what changed between
revisions A and B. "svn blame foo" shows you the revision in which
each line was added or changed, and who did it. These are much better
ways of determining what's going on with the files than by looking at
a revision number, whether it's per-file as in CVS or per-repository
as in Subversion.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 14 22:53:17 2006