Re: Feature request: Keyword $Rev$ with a twist

On 31 Jul 2002, Ben Collins-Sussman <sussman@collab.net> wrote:
> William Uther <will+@cs.cmu.edu> writes:
>
> > If I remember correctly, this has come up before. The issue is svn supports
> > mixed revision working copies (again, IIRC). You cannot guarantee that the
> > value in any file is up to date for any other file in the working copy. If
> > you add this keyword in the file revision.h, and then 'svn up' a dir that
> > doesn't contain revision.h, then revision.h will not be updated and will be
> > contain incorrect information.
>
> I think that we've all agreed that we don't want to put the
> working-rev into our Subversion's *own* svn_version.h header. But I
> don't think anyone is particularly against the creation of a
> $WorkingRev$ keyword.

Suppose I have version.h in my working copy, and I svn up to get new
changes. version.h has not actually had any changes committed, but my
local copy changes to get the new $WorkingRev$. Presumably its mtime
needs to get updated to the current time.

Excuse me if I'm confused, but that seems like quite a change from the
current CVS and Subversion behaviour, which is not to touch files that
have not changed in the repository.

So, if this change was accepted, would every file in the current
directory be updated? (Therefore, make will always rebuild everything
after svn up.) Or would only files containing $WorkingRev$ be
updated? That sounds a little wierd.

Or does the variable only get updated when the file is "really"
updated? So to be sure of getting the right version, I'd need to rm
and re-update the file.

I don't really object to the feature and I can see how it would be
useful, but I'm curious how it would work.

-- 
Martin 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org