Julian Foad wrote:
> You don't say what SubWCRev is or does [snip]
My english blows, but I'll give it a shot. Please bear with me for a moment.
I'm using GoogleMail, if this posting is malformed (lines too long,
etc.) please let me know!
Skim towards 'Proposal' if you're real lazy.
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$ ?
Surprise, it won't work.
The $Revision$ number will reflect the last committed revision of the
particular file it's in.
But I could've easily modified one of the other 4 files and thereby
changed the entire project, without this fact reflecting in the final
project's compiled-in revision number.
Dare I say it, but this seems to render the $Revision$ keyword most unusable.
What's needed
================
We need a keyword that says something about the project as a whole.
The SubWCRev Way
===================
SubWCRev finds which file in the current WC (and below) has the newest
'last committed revision' and uses that number instead.
It then reads your SVN'ed source files and replaces all $SUBWCREV$
keywords in their entirety with the revision number it finds.
That differs a bit from the Subversion way of modifying the yyy part
of a $xxx: yyy$ string, but that's a minor detail, so forget about
that for the time being.
The big disappointment with SubWCRev is that it saves the resulting
data into a whole new source file, which we'll call the "result file".
In fact, it can do little else, since saving into the original source
file would be considered a file change by Subversion, which would have
to be committed.
Committing would bump the revision number of the project even though
nothing had actually changed - bad.
Also, it would cause another SubWCRev rev bump, leading to another
commit, ... there we have an infinite loop.
What's wrong with SubWCRev?
==============================
The problem with SubWCRev is that it integrates not-so-well with Subversion.
SubWCRev can't do in-file keyword expansion as Subversion does for the
reasons stated above.
That unfortunately leads to a lot of work for every Subversion project
that wants to use revision keywords.
Here's an outline of the work that those projects could be spared for.
1.)
Developers has to be taught not to modify the result files. In fact
it is worse:
Since the result files are referenced from other source files and the
dev environment, developers actually has to be taught that they must
_check_ every file they want to muck with to see if it's actually a
file resulting from a SubWCRev run, in which case they have to modify
a whole 'nother file instead. Ack.
2.)
The build environment (scripts, whatever) needs a bunch of modifications.
3.)
Every SubWCRev result file has to be svn:ignore'd.
4.)
It requires a whole extra tool to do something that is actually
really, really basic (or at least it would be if it was part of svn).
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.
The keyword is expanded when 'svn update' or 'svn commit' is executed.
Subversion regards the keyword as any other keyword, eg. if it changes
it's not really a file change.
That's basically it.
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
b.) Traverse sub-WC folders too.
If we want the keyword to reflect status in sub-WC folders also,
discrepancies might occur when sub-WC-folders are updated
independently.
We may either:
c.) Document that keywords are *only* updated when 'svn up/co' is
executed, and so may be "out of state" if sub-WC-folders are updated.
d.) Make 'svn up/co' traverse parent folders and update keywords.
Either way (a or b:c or b:d) seems fine to me, however I lean towards
a.) for it's simplicity.
There's also the small kink of mixed revisions.
The keyword is meant to represent the revision of the working copy as a whole.
If that cannot clearly be determined because different parts of the WC
has been updated to different revisions, let's just expand the keyword
to "mixed" or perhaps "mixed (min:max)".
> If you still think it's realistic to make this a feature of Subversion,
> start a mail thread about it, with a design proposal.
Thank you for the friendly reminder; hereby done.
Hope it doesn't suck too much!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 29 13:24:51 2005