On 11/14/2006 12:21 PM, John Rouillard wrote:
> On Tue, Nov 14, 2006 at 09:54:45AM -0500, Duncan Murdoch wrote:
>> On 11/14/2006 9:21 AM, Les Mikesell wrote:
>> >On Tue, 2006-11-14 at 01:38, Tim Hill wrote:
>> >>Actually I think the single rev# is one of the best features of SVN.
>> >>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,
>
> Hence the problem. If you think of revision numbers as the count of
> the number of revisions of the file not the repository. A file
> activity counter if you will, then you loose information with the
> repository version number. Both ways are right and wrong depending on
> how the files relate to each other.
That's not a good measure of the amount of activity, because a rev
number can change when you fix a typo or change spaces to tabs, or when
you completely rewrite the file. A better measure of the amount of
activity is the size of a diff of the file, but even that is imperfect:
changing spaces to tabs may look big if it affects lots of lines, even
though it is nearly content free.
> In my case I have to cherry pick files at different revisions into a
> single tag all the time because the files are loosely coupled but
> deployed as a single entity (system configuration) but I currently
> have 40 or so subsets of files that are totally independent. So I get
> revision 1026 of the ssh keys files, revision 223 of the ssh config
> files, revision 2230 of the ldap config files etc.
>
> (These revisions aren't always the same version I would get by
> checking out the HEAD revision of the tree. I have sort of abandoned
> this because of how difficult it is to track this where it was easy
> under CVS with floating tags, but I digress.)
>
>> they are just
>> as meaningful whether they increase sequentially or by bigger jumps.
>
> If I want to see how many versions of an ldap config file has been
> released, I have to go to the log messages and look at all the
> revisions and count them (or use a program to do the same).
That's where svn is lacking, it doesn't give you an easy way to count
the tags on a file, which cvs does. This doesn't have anything to do
with revision numbers on files versus the repository, it has to do with
limitations in current svn tools.
I think you could write a script to search the entire log to find how
often a file had been copied to the tags hierarchy, and list all the
tags, but it would be slow. The problem is that the current svn log
attaches no information to the source of the copy, only to the
destination. It would be nice if you could look at the log of a file
and see where it was copied *to*, as well as where it was copied *from*.
> Where
> revision 1.6 of the file tells me I have had 6 copies of the file with
> no requirement to be able to access the repository. If I know that the
> file is at revision 2010 in svn, does that tell me anything about the
> number of releases of this file? It does tell me about the repository,
> but if I only want a file number because it has no relation to the
> repository as a whole (e.g. a document rev number) then...
Rev 1.6 doesn't tell you about the number of releases, only the number
of revisions on the trunk, but as I said above, that doesn't really
measure how much activity there has been.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 14 21:57:18 2006