Molle Bestefich wrote:
>
> The $Revision$ keyword
> ========================
> Say I have a project, 5 source files that compile to 1 executable.
> I stick the $Revision$ keyword in one source file to get the revision
> number compiled into the final project.
>
> I'm guessing this is the main use case for $Revision$ ?
No, you've guessed wrong. The "Revision" keyword is mainly used in the header
comments of a file so that a copy or paper print-out of the file can be traced.
> Dare I say it, but this seems to render the $Revision$ keyword most unusable.
Unusable for what you want, but very usable for its proper purpose. OK, that
was just a misunderstanding. Let's move on.
> What's needed
> ================
> We need a keyword that says something about the project as a whole.
You want a way of getting information about your working copy of the project
into one of your working copy files. You have your reasons for arguing that
this should be done by Subversion through its "keyword" mechanism, but whether
that is the best solution is disputed.
I'll try to summarise the main viewpoints objectively. There may be truth in
the view that this feature doesn't fit conceptually. On the other hand, some
people's fears about implementation complexity are exaggerated.
THE MAIN VIEWPOINTS
PRO:
Having Subversion put this info into your files would avoid the need for any
external programming by the user.
Subversion already exposes some information about revision numbers through its
Keywords mechanism, and so it seems natural and obvious that any such
information should be exposed that way.
CON:
Some people have said that it can't be implemented efficiently. That depends,
of course, on exactly what is to be implemented, but I do not believe it.
There are exceedingly few problems that cannot be computed efficiently and
there is no reason to think this is one of them. To assume that the
implementor of this feature would do a poor job is irrational.
The correctness of a feature that says something about "the whole working copy"
depends on the reliable definition of "the whole working copy". Subversion, so
far, does not have such a concept. Therefore, adding this feature requires
defining this concept. (See below.)
> Proposal
> ===================
> Add support for a new keyword to Subversion, for example
> "$WorkingCopyRevision$".
>
> The keyword reflects the newest (highest) "last comitted revision" of
> any item in the current working copy.
This is one of the awkward problems: what exactly does "in the current working
copy" mean? Subversion has always regarded a directory tree as an independent
Working Copy, recursing down into it but never looking up outside it. Should
Subversion traverse up through parents and down through children to find all
directories that are connected by parent/child relationships to the specified
target directories and files? Don't just say "yes" or "no"; consider the
implications.
I think maybe the concept of a "whole working copy" exists in some of the
third-party Subversion clients such as TortoiseSVN; if so, maybe this feature
would fit better in them.
> The keyword is expanded when 'svn update' or 'svn commit' is executed.
Executed on what set of targets relative to the files in which the keyword
needs to be expanded?
> Subversion regards the keyword as any other keyword, eg. if it changes
> it's not really a file change.
> Details
> ==========
> 'svn up/co' need to modify other files in the current WC besides those
> that are being updated/committed, in order to mak sure that keywords
> contain values consistent with the current working copy state.
>
> Also, 'svn up/co' could either:
> a.) Be restricted to checking revisions in the current WC folder,
> which might be too narrow, or
[Paraphrasing your other options]
b:c) (Was later dismissed)
b:d) Traverse sub-folders and parent folders.
> Either way (a or b:c or b:d) seems fine to me, however I lean towards
> a.) for it's simplicity.
Please clarify what exact behaviour you mean by (a).
In summary, I am neutral on whether we want this feature, and I was neutral on
whether it could reasonably be done, but after thinking about it some more I
think the "whole working copy" concept is one that does not exist nor fit
easily into the existing "svn" command-line client, and so this feature belongs
in higher-level software. However, I am still open to discussion.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 16:53:48 2005