You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Micha Bieber <kr...@users.sourceforge.net> on 2005/06/03 09:10:28 UTC
[Feature] unique version numbers
@list,
I'm not sure, if this belongs to this list or the user list. Anyway, the
feature seems not to be implemented, so I'm asking here:
The following FAQ topic deals with unique version numbers:
http://subversion.tigris.org/faq.html#version-value-in-source
It would be nice to have this feature in a platform-independent way as a
part of subversion. Putting build numbers/dates etc. in executables
are quite common for e.g. nightly builds. Is this possible for
subversion ?
Anyway, thank you for your great software,
Micha
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> If we store the value, then we only have to do extra work for files
> which use the offending keywords (GlobalRevision for update, URL and
> GlobalRevision for switch).
And we are storing exactly the same information in both the entries file
and the props/file.svn-work file (in different forms).
How about this as a compromise: store a new value in entries, say
'requires-keyword-expansion' and set that at an appropriate time that we
are already rewriting the entries file (say update) iff one of the
defined keywords is set on this file (currently URL and GlobalRevision).
Then we have the best of both worlds: we only need to read the entries
files to know which files need updating and we use the existing keywords
expansion code to rewrite the file(s) without having to special case the
coding.
It should always be safe to completely re-expand any existing keywords
(since the values either changed or didn't change) and we are just
flagging those files where we *have* to change them. We might wind up
rewriting a file with an unchanged $URL$ but it is a much simpler
interface to program, since it just uses the current API.
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
Re: [Feature] unique version numbers
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-06-03 at 11:13 -0400, John Peacock wrote:
> It should be sufficient to just store a flag noting the *presence* of a
> svn:keywords in the entries files. Right now you only want to have
> $URL$ and possibly $GlobalRevision$ get autoexpanded; later there might
> be others and it is easy to retrieve the actual svn:keywords value after
> locating which files need special handling...
That doesn't seem right. If we just flag the presence of svn:keywords,
then we have to read the props of every keyword-enabled file in the
working copy after every switch (and every update, for the global
revision keyword). That's substantially slower than what we do now,
which is just read and rewrite the rev files.
If we store the value, then we only have to do extra work for files
which use the offending keywords (GlobalRevision for update, URL and
GlobalRevision for switch).
Of course, storing the keywords value in the entries file is itself a
cost. It's not a very big cost intrinsically, but I'm not sure if we
are in a good position to know the keywords value every time we write an
entry, and it would be a shame to add more rewriting of entries for this
purpose.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Er, no, the whole point of #1975 is that $URL$ needs to be rewritten in
> all files, not just the ones which changed as a result of the switch
> operation.
I swear when I read #1975 the first time it said something about passing
a list of the switched files after the update so the client could update
the keywords. It doesn't say that now, so apparently the hallucinations
are getting worse... ;-)
>
> The trick is to only re-substitute the files which have the offending
> keyword in their svn:keywords properties. Doing that efficiently might
> require storing the svn:keywords value in the entries file.
It should be sufficient to just store a flag noting the *presence* of a
svn:keywords in the entries files. Right now you only want to have
$URL$ and possibly $GlobalRevision$ get autoexpanded; later there might
be others and it is easy to retrieve the actual svn:keywords value after
locating which files need special handling...
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
Re: [Feature] unique version numbers
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-06-03 at 10:52 -0400, John Peacock wrote:
> Greg Hudson wrote:
> > However, there is some hope. In
> > http://subversion.tigris.org/issues/show_bug.cgi?id=1975 I noted that
> > the solution to a fairly obscure bug ("svn switch" doesn't update $URL$
> > values) looks very similar to an implementation of $GlobalRevision$.
>
> Not to throw cold water on this, but in the 'svn switch' case, we know
> what files were "switched" and hence we know which files need to be
> checked for re-expansion of keywords.
Er, no, the whole point of #1975 is that $URL$ needs to be rewritten in
all files, not just the ones which changed as a result of the switch
operation.
The trick is to only re-substitute the files which have the offending
keyword in their svn:keywords properties. Doing that efficiently might
require storing the svn:keywords value in the entries file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> However, there is some hope. In
> http://subversion.tigris.org/issues/show_bug.cgi?id=1975 I noted that
> the solution to a fairly obscure bug ("svn switch" doesn't update $URL$
> values) looks very similar to an implementation of $GlobalRevision$.
Not to throw cold water on this, but in the 'svn switch' case, we know
what files were "switched" and hence we know which files need to be
checked for re-expansion of keywords. In the ordinary 'svn ci' case, we
have no list of files to use as the basis for re-expansion, so I don't
think that fixing 1975 will help much in the generic $GlobalRevision$.
Unless there is some way to flag a specific file or files as requiring
keyword expansion on every commit/switch/etc, we are left with the
unpleasent task of walking the WC to look for svn:keywords and
potentially re-expanding those files.
It may be better to create a new option which specifically force a
re-expand on all keywords in the WC. Thus, the people who don't need
this feature don't get this hit; people who do want this can do:
$ svn ci -m 'something' --force-expand-keywords
and the client code will perform an additional walk at the end to DTRT.
There should also be a way to trigger this re-expand independently (so
that projects which only store the $GlobalRevision$ in one file or in
one directory can use a non-recursive fashion).
John
p.s. I've added this thread to the incident for future reference
--
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
Re: [Feature] unique version numbers
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-06-03 at 11:10 +0200, Micha Bieber wrote:
> It would be nice to have this feature in a platform-independent way as a
> part of subversion. Putting build numbers/dates etc. in executables
> are quite common for e.g. nightly builds. Is this possible for
> subversion ?
It's not likely to happen any time soon, for reasons other people have
gone into. (It doesn't fit nicely into our architecture and would
require a lot of care to avoid performance issues.)
However, there is some hope. In
http://subversion.tigris.org/issues/show_bug.cgi?id=1975 I noted that
the solution to a fairly obscure bug ("svn switch" doesn't update $URL$
values) looks very similar to an implementation of $GlobalRevision$.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by Erik Huelsmann <eh...@gmail.com>.
On 6/3/05, Micha Bieber <kr...@users.sourceforge.net> wrote:
> Friday, June 3, 2005, 13:39:13, John Peacock wrote:
>
> > The usefulness of any feature has to be weighed against the performance issues
> > involved.
>
> Because it is a pretty often needed feature for many regular
> build processes, I jumped in here with the request - completely innocent
> from a users point of view. I understand of course, that you have to
> care for your current implementation. Thats the developers view, I'm the
> user, as always merciless ... :-)
> > Tell us what language you are mostly concerned about (since the FAQ covers
> > a way to do exactly this in C)
> Do you talk about the link from my original posting or do I miss
> something ? As far, as I can see the mentioned solution is platform-dependent.
> Yes, I'm using C++. But to be frankly, I would prefer a generic solution
> using a special keyword usable for any kind of project.
> I really think, it's desirable not only for me alone.
Well, the problem is that there is only one way to do it correctly:
use the $Revision$ keyword in every file. This is because the working
copy is not necessarily (actually, almost never) all at the same
revision level and thus it's never possible to accurately describe
exactly what you built if you don't include all versions of all files.
See the Subversion Book section about mixed revisions.
> Micha
>
> p.s. Is CC'ing common on this list ?
Yes, it is. If you don't want that, then, please tell me, so I can
stop doing it for you.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by Marcus Rueckert <da...@web.de>.
On 2005-06-04 00:47:03 -0700, Kenneth Porter wrote:
> Does someone have a recipe that can be used with a VC7 project file? I'm
> building the Linux side of a cross-platform project, using a Makefile, so I
> can use the stuff in the FAQ, but I need something I can give the Win32
> guys to put in their project file.
http://tortoisesvn.tigris.org/download.html
at the bottom you have SvnWCRev.exe
darix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Friday, June 03, 2005 9:56 AM -0400 John Peacock <jp...@rowman.com>
wrote:
> Yes, the example code is specific to compiled/linked applications using a
> Makefile, but in any non-trivial project, there will be some sort of
> build process that can (in general) be leveraged to perform exactly the
> same kind of transformation. That's why I asked about what language you
> were using so we could suggest a way to use svnversion to extract that
> information as part of the normal build process. It's not going to be
> platform-independent, but it can be done everywhere, just differently.
Does someone have a recipe that can be used with a VC7 project file? I'm
building the Linux side of a cross-platform project, using a Makefile, so I
can use the stuff in the FAQ, but I need something I can give the Win32
guys to put in their project file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by John Peacock <jp...@rowman.com>.
Micha Bieber wrote:
> Because it is a pretty often needed feature for many regular
> build processes, I jumped in here with the request - completely innocent
> from a users point of view.
Which is why there is a FAQ entry for how to accomplish it. Perhaps we
can improve the FAQ answer but there is no way to do anything different
given the nature of the existing WC code. It's not a matter of how
difficult it would be to add to the codebase; it is that without a
[pretty much complete] redesign, any change that would cause massive
slowdowns for _all_ users, not just the ones who wished to use this feature.
I'd recommend reading through the section of the book on Revisions:
http://svnbook.red-bean.com/en/1.1/ch02s03.html#svn-ch-2-sect-3.2
and especially the section on "Limitations of Mixed Revisions" as this
touches on why a $GlobalRev$ keyword would be bad for performance. The
short answer is that the only time that keywords get updated in a file
is when the file is updated, and to have a $GlobalRev$ keyword would
normally require updating the entire WC after every commit (which for
large projects would be a massive slowdown). See Greg's message for a
possible way to shortcut that search/replace, but it isn't guaranteed
that this will be acceptable performance-wise either.
> Do you talk about the link from my original posting or do I miss
> something ? As far, as I can see the mentioned solution is platform-dependent.
Yes, the example code is specific to compiled/linked applications using
a Makefile, but in any non-trivial project, there will be some sort of
build process that can (in general) be leveraged to perform exactly the
same kind of transformation. That's why I asked about what language you
were using so we could suggest a way to use svnversion to extract that
information as part of the normal build process. It's not going to be
platform-independent, but it can be done everywhere, just differently.
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
Re: [Feature] unique version numbers
Posted by Micha Bieber <kr...@users.sourceforge.net>.
Friday, June 3, 2005, 13:39:13, John Peacock wrote:
> The usefulness of any feature has to be weighed against the performance issues
> involved.
Because it is a pretty often needed feature for many regular
build processes, I jumped in here with the request - completely innocent
from a users point of view. I understand of course, that you have to
care for your current implementation. Thats the developers view, I'm the
user, as always merciless ... :-)
> Tell us what language you are mostly concerned about (since the FAQ covers a way
> to do exactly this in C)
Do you talk about the link from my original posting or do I miss
something ? As far, as I can see the mentioned solution is platform-dependent.
Yes, I'm using C++. But to be frankly, I would prefer a generic solution
using a special keyword usable for any kind of project.
I really think, it's desirable not only for me alone.
Micha
p.s. Is CC'ing common on this list ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by John Peacock <jp...@rowman.com>.
Micha Bieber wrote:
> The only things I was able to find, are performance issues. It doesn't
> touch the usefulness of the feature in principle.
The usefulness of any feature has to be weighed against the performance issues
involved. Adding something that scans the entire WC on every commit, just on
the off chance that some file might be using the $Version$ keyword would be a
huge performance hit for everyone. Not to mention that mixed revision working
copies, it is perfectly legitimate to have most of your WC be one or more
revisions back most of the time.
Tell us what language you are mostly concerned about (since the FAQ covers a way
to do exactly this in C), and perhaps someone can suggest another way to get
what you want.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by Micha Bieber <kr...@users.sourceforge.net>.
> That's why the faq exists.
?
> If you want to know why it does not exist, then check out the users@ and
> dev@ list archives at http://svn.haxx.se/ . They contain a lot of discussion
> why this feature does not exist.
The only things I was able to find, are performance issues. It doesn't
touch the usefulness of the feature in principle.
Micha
--
ps. Please don't CC'ing me. I read this list and there is no need to get
the message twice.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Feature] unique version numbers
Posted by Erik Huelsmann <e....@gmx.net>.
> --- Ursprüngliche Nachricht ---
> Von: Micha Bieber <kr...@users.sourceforge.net>
> An: dev@subversion.tigris.org
> Betreff: [Feature] unique version numbers
> Datum: Fri, 3 Jun 2005 11:10:28 +0200
>
> @list,
>
> I'm not sure, if this belongs to this list or the user list. Anyway, the
> feature seems not to be implemented, so I'm asking here:
>
> The following FAQ topic deals with unique version numbers:
>
> http://subversion.tigris.org/faq.html#version-value-in-source
>
> It would be nice to have this feature in a platform-independent way as a
> part of subversion. Putting build numbers/dates etc. in executables
> are quite common for e.g. nightly builds. Is this possible for
> subversion ?
Yes it is. The faq explains one of the ways to do it. If you're asking for a
keyword to do it, then, no, that doesn't exist. That's why the faq exists.
If you want to know why it does not exist, then check out the users@ and
dev@ list archives at http://svn.haxx.se/ . They contain a lot of discussion
why this feature does not exist.
bye,
Erik.
--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org