Re: Proposal for $Revision$ keyword amendment

Molle Bestefich wrote:
> However, we don't use Makefiles.
> We use VS.Net's build system, in which it is not practical to do
> something like the above.
> I imagine the same is true for other build systems..

I'm sure that there is a way to create a build step, even in as
primitive a tool as VS.Net ;-), that runs some script prior to compiling
a given file. See this FAQ for the recommended way to do it with a
Makefile:

http://subversion.tigris.org/faq.html#version-value-in-source

and adapt that for use with VS.Net (then submit a patch to the FAQ so
that others can use it too).

> Option b:c mentioned above is on second thought not acceptable, since
> the whole point of integrating the keyword in 'svn co/up' is to make
> the rev number(s) in the WC consistent upon commit/update, just like
> the other keywords. Options a.) and b:d.) are still fine solutions,
> though ;-).

But the piece you are missing is that Subversion _only_ updates keywords
on files that have *changed*, plus see issue:

        http://subversion.tigris.org/issues/show_bug.cgi?id=1975

for a situation where Subversion *doesn't* update keywords when it should.

You are also papering over the situation where your WC is in a mixed
revision state, which is true anytime you checkin and don't immediately
update. SubWCRev gets around this by finding the highest rev in the WC
and returning that. But that still may not accurately reflect the
actual state of the WC. It is entirely possible to backrev a portion of
the build tree, say a sub-library which has to be kept stable for
releases even though further development has occurred in that section of
the code.

My primary beef with this whole thread is that Revision is a bookkeeping
value that arises out of internal implementation of the repository
architecture and should not be elevated to any greater significance
(i.e. something like a version number). Revision is moderately useful
to developers in the actual act of developing software under *certain*
circumstances, but because it is a single value that is global to the
repository, there are plenty of situations where the value of "Revision"
does not have any way to capture the complexities of a deliberately
mixed revision WC.

If you want to ensure that you can find the corresponding set of files
for a given release, use the same methodology as Subversion employs:

1) Branch for the release, complete testing and any integration to the
branch until ready to release.

2) Tag the branch and release off the tag, using a tag name which
corresponds to the externally visible package name.

Only by creating a tag, which will encapsulate mixed revision
development, can you be guaranteed to be able to go back later and
recreate a given set of files accurately.

HTH

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org