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

Re: Proposal for $Revision$ keyword amendment

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-10-04 21:39:09 CEST

Greg Hudson wrote:
> You're oversimplifying. $UpdateRev$ would require additional machinery
> to implement, but it would not imply any tremendous architectural or
> performance issues.

Yes, I am oversimplifing, because Molle seems to expect that Subversion can
somehow magically know which files contain $UpdateRev$ and update those files
even when they have not otherwise changed.

I also don't think you've thought this through all that much either. Yes, it
would be possible to check the entries file to locate the files with the
UpdateRev keyword for substitution during the normal update process. But it is
trivial to come up with a scenario that will not work correctly that way:

$ svn co project1
$ cd project1
$ vi lib/some/deep/directory/file1.c
$ svn ci -m 'look Ma, no recursive checkin' lib/some/deep/directory/file1.c
$ make

Now unfortunately, the top level include file with $UpdateRev$ was not part of
that commit, so Subversion has no way to update it unless the entire WC is read
(granted just the entries files). That has to be some performance hit, even if
you don't think it is significant.

Additionally, only by scanning the entire WC can you even determine what value
should be plugged in to that field. Consequently, even if you enumerate the
files that need updating, an additional loop after the normal check-in
processing would be required to substitute that value. I would argue that this
is a significant architectural change, since all of the current code operates
under the "I'm here, this is what I know, this is what I need to do" mode of
operation, completely oblivious to the rest of the WC.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 4 21:40:11 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.