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

Re: introduction, and some comments

From: Rob Clark <robdclark_at_mac.com>
Date: 2002-12-27 18:05:32 CET

On Thursday, December 26, 2002, at 11:30 PM, Michael Wood wrote:

> On Thu, Dec 26, 2002 at 06:42:46PM -0800, Rob Clark wrote:
> [snip]
>> "populate"
>> ----------
>>
>> it would be nice to have a command to automatically add/remove files
>> that have been added/removed since the last checkout/update, like with
>> prcs's populate. Perhaps file properties on the directory could be
> [snip]
>
> My understanding is that tools/client-side/svn_load_dirs.pl was written
> with this sort of thing in mind. I've never tried it though.

I'll have a closer look at svn_load_dirs.pl... when I first looked at
it I thought it was intended for initial population of the
repository... what I had in mind was more of a convenience so the user,
after doing some development which adds/removes files, they didn't have
to "svn add" and "svn rm" each of those files.

>
>> keywords
>> --------
>>
>> From looking through the mailing list archives, this has come up
>> before. Having per-file keywords is fine, and I will be using them
>> for
>> sure, but it will be a step backwards from prcs to not have
>> per-project
>> (per-repository) keywords, at least when I export a release. I think
>> a
>> compromise solution would be a way to have an export-hook script which
>> would run on the server when a client is doing an export... if that
>> export script was able to modify the files sent to the client, then I
>> could implement my own keyword substitution.
>>
>> I am not sure if export is a client side only thing, or not... if it
>> is
>> client side only, then maybe I could do the same thing with a checkout
>> hook that did the keyword substitution, and perhaps a commit hook that
>> undid the substitution.
>
> AFAIK svn export is implemented as a checkout and then removal of all
> the .svn directories. There is currently no checkout hook, but if you
> have keyword substitution set for all the files you're interested in,
> then the checkout process will expand all the keywords for you anyway.
>
> I assume you mean you don't want to have to apply the same svn:keywords
> property to every file in your huge repository and every time you add a
> new file instead of once for the whole repository?

that isn't really the issue... I can write a bit of shell script to set
the properties of each existing src file (although if svn had a
populate feature, it would be nice to have a way of specifying default
properties for new files... I guess this would be useful for "svn add"
as well.). What I am really after if a way to have a project revision
keyword, rather than a file revision keyword. (Maybe I am mistaken,
but from what I understand the keywords will only tell you the last
revision that the current file was changed.)

Basically I'm just looking for a way to spin a release without having
to use a script to go and fix up all the files that need the project
version number embedded in them.

>> keywords 2
>> ----------
>>
>> a $Format: "some string"$ keyword, which replaces the following line
>> with the specified string with all keywords expanded... for example,
> [snip]
>
> There is an issue filed for this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=890
>
> If you need this sort of thing before issue 890 is resolved, it's not
> very difficult to add your own keyword to your copy of svn.
>
> So you could add a $oscript$ keyword which expands to whatever you
> need.
>

Oh, very cool!

Can the pre-commit hook script set properties? If so perhaps I could
do something with %p and a property that is set to the project version
number at checkin.

-- Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 27 18:07:05 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.