[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-10-04 21:57:10 CEST

On Tue, 2005-10-04 at 15:39 -0400, John Peacock wrote:
> I also don't think you've thought this through all that much either.

Then I think you haven't been reading what I've written in this thread,
or not understanding it.

> 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

That would work correctly. The top-level include file with $UpdateRev$
in it correctly reflects the *working copy revision of that file*, as
recorded in the entries file. Only when we change the entry for a file
do we have to worry about re-expanding its $UpdateRev$ keywords.

No, we cannot make it magically update to reflect the mixed-rev state of
a working copy without making unacceptable architectural compromises.

If your argument is "this feature is worthless unless it does all the
magic we can't do", then that's consistent (though not compelling, to
me). But what's frustrating is that you're not phrasing your argument
that way. You're assuming I want to do the impossible magic, arguing
that it can't be done, and leaving it at that.

---------------------------------------------------------------------
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:58:27 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.