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

RE: new substitution keyword for global repository revision

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 24 Dec 2009 12:08:32 +0000

On Thu, 2009-12-24 at 12:48 +0100, Bert Huijben wrote:
>
> > -----Original Message-----
> > From: Christian Schoenebeck [mailto:cuse_at_users.sf.net]
> > Sent: donderdag 24 december 2009 11:17
> > To: dev_at_subversion.apache.org
> > Subject: new substitution keyword for global repository revision
> >
> > Hi!
> >
> > I would like to work on introducing a new substitution keyword which
> always
> > reflects the latest repository revision. A client side way with svnversion
> > embedded into a Make file or something is not a solution for me.
> >
> > I'm not used to the subversion code base yet. Just chased a bit over the
> > trunk
> > version code so far. So I would be very happy if somebody could give me
> > some
> > pointers where I should put my hands on for this task!
> >
> > In r875460 the "Header" substitution keyword was introduced. According to
> > those changes, I probably need to introduce a new function
> > svn_subst_build_keywords3() with an additional function argument so I can
> > somehow resolve the repository revision.

Yes, if you want to play with the idea, that's a good place to start.

> > Any comments appreciated!

This has been discussed many times over the years. Have you read the
past discussions?

> This solution won't work, because Subversion only updates files if they are
> already updated for other reasons. You would have to fix that (and thereby
> make the average update command much slower).

With WC-NG and centralized metadata it would not necessarily be slow
(assuming not many files have the keyword).

- Julian

> Your keyword would require updating all files with this keyword, all the
> time. And even then it wouldn't properly support mixed revision working
> copies. (How do you plan to resolve this?)

> You should really look at using the revision from some kind of build system
> that performs/assumes a full update. Only then you can avoid these issues.
>
> Bert
Received on 2009-12-24 13:09:12 CET

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.