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

Re: Global revision keyword - why it is impossible

From: Duncan Murdoch <subversion_at_murdoch-sutherland.com>
Date: 2004-10-28 04:11:20 CEST

On Thu, 28 Oct 2004 00:11:42 +0100, "Max Bowsher" <maxb@ukf.net>
wrote:

>The problem:
>
>To accurately represent the state of the tree, as svnversion does, we must
>not only know which revision the tree is at, but also whether it is
>modified - otherwise, a plain revnum can mislead.
>
>There is no feasible solution that can cause spontanteous update of a
>keyword in one file when a distant file within the same set of working copy
>dirs is changed.
>
>If we (riskily) decide to live without a 'modified' flag:

I don't see why you call this "risky". "svn info ." doesn't give as
much version information as "svnversion ." does, but it's still
useful.

>
>Then the problem is still awkward - any "svn update" or "svn switch" must
>update files which possibly lay *outside* the area of tree on which they are
>acting.

I don't see why someone would ask for that. I would only want svn
update to change a file if I asked for that file to be updated. If
the file had a $globalversion$ keyword in it, then I'd have no reason
to complain if it was wrong when I hadn't chosen to update it. I'd
want the keyword substitution to apply to that file when that file was
updated, not at other weird times.

>This would represent a significant new subsystem of code just to support
>this one keyword, to produce an end result which is still inferior to
>svnversion.

What I *would* want, and this is probably new but I don't know how
major, is for some files to be automatically marked as modified in the
repository whenever any file is checked in. If this were done with
regular keywords, it would be a reasonably heavy burden: those files
would have to be tracked down and found. But presumably this keyword
could be handled specially, so the repository knows the list of files
that contain it and automatically marks them as modified.

Duncan Murdoch

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 28 04:11:35 2004

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

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