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

Re: [Feature] unique version numbers

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2005-06-03 14:21:34 CEST

On 6/3/05, Micha Bieber <krischnamurti@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
Received on Fri Jun 3 14:23:14 2005

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

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