[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] #2219 canonicalized keyword and new UUID keyword documentation

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-20 20:26:34 CET

On Mar 20, 2005, at 11:49 AM, John Peacock wrote:

> Ben Collins-Sussman wrote:
>> How about the term 'locks'? We have working-copy locks, shown by
>> 'L' in the status command. BerkeleyDB has private locks that it uses
>> for mutexes and things ("out of locks" errors). 'svnadmin recover'
>> and FSFS both take out locks on ordinary files, to manage concurrent
>> writes ("trying to get exclusive lock..."). And now we have a
>> locking feature, allowing users to create locks in the filesystem.
>
> That's a good argument, except that each and everyone one of those
> concepts is almost the same thing (a way to limit resource access to a
> single process). "Revision keywords" are almost nothing like the
> keywords concept that svn:keywords embodies. HEAD /et al/ are aliases
> for certain revision numbers; they share no common behavior with the
> keywords in files (a concept that Subversion inherited from CVS,
> granted).
>

I think the word 'keyword' is being used generically in both cases:
"here's a special word that causes something to happen."

> I'm not that worked up about it, except for the fact that in the index
> of the book, the section "Revisions: Numbers, Keywords, and Dates, Oh
> My!" is given prominent billing in the "Guided Tour," but the
> potentially much more useful information about expanding keywords in
> files is listed somewhat obliquely in "Advanced Topics" under "Special
> Properties."
>

For a beginning user first being introduced to version control, or even
just Subversion, I think they're *far* more likely to use 'revision
keywords' in basic day-to-day work than the 'svn:keywords' feature...
don't you think? The first feature helps you navigate around history.
If I were new to version control, I wouldn't even imagine the
*existence* of the latter feature, until someone told me about it. ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 20 20:27:46 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.