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

Re: 'stamping' a la RCS '$Header$'?

From: <cmpilato_at_collab.net>
Date: 2002-05-03 05:26:39 CEST

Eric Gillespie <epg@pretzelnet.org> writes:

> Karl Fogel <kfogel@newton.ch.collab.net> writes:
> > Yeah. We had some proposals for a super-sophisticated keyword "alias"
> > mechanism, where people could define custom combination keywords. But
> > it was never clear where the mapping would be stored (or maybe I'm
> > just not remembering the proposals well enough?)
> I proposed a format string solution, but didn't know enough about
> svn to comment on implementation details. Now i know a bit more,
> and have an idea: put the information in directory properties.
> For example, if svn:keywords lists an unknown keyword 'foo' check
> for the presence of a property custom-keyword:foo on the current
> directory and keep climbing up the directory tree until you find
> one. If you don't find one, don't expand it, if you do, expand it
> to the string specified there, replacing format specifiers.
> So i could set svn:keywords to 'Progeny' on all the files we modify
> and set custom-keyword:Progeny to '%f %r %d %a' on /trunk. %f is
> base filename (which svn doesn't currently support but should), %r
> is revision, %d is date, and %a is author.

Yeah, see the problem here is that you set your format string property
on trunk. But what if I only check out some sub-tree under trunk?
This scenario will inevitably lead to setting your format string
property on every directory (since you don't know what portion of the
tree folks will check out). But if you're going to be setting the
same property so many times, why not set it instead only the files
that want to expand it?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 3 05:31:04 2002

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.