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

Re: Version-value-in-source alternative proposal

From: Matt England <mengland_at_mengland.net>
Date: 2006-01-26 05:02:24 CET

Here's another problem with the current
<http://subversion.tigris.org/faq.html#version-value-in-source> solution:

My team can't use 'svn export'-ed code to build...assuming 'svnversion .'
requires the .svn meta-data dirs. Up until now, our build procedure for
official builds called for 'svn export'-ing the source dirs, creating a
tar-ball "snapshot", saving the snapshot in an archive (because repos of
any kind can one day get corrupted), and building the build from said
"source snapshot."

One can presumably not do this with
<http://subversion.tigris.org/faq.html#version-value-in-source> but could
do so with the proposed solution below.


At 1/25/2006 09:14 PM, Matt England wrote:
>I offer an additional alternative to the current 'svnversion -n'
>implementation of
><http://subversion.tigris.org/faq.html#version-value-in-source> that
>requires feature enhancements to the Subversion system:
>Define a $GlobalRevision$ keyword and a repo property (call it
>'svn-global-revision-files') that allows a repo admin to list all files
>with $GlobalRevision$ contained in them. Every client checkout/update
>will force a svn client to check for all files listed in
>'svn-global-revision-files' for $GlobalRevision$ and update said keyword

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 26 05:03:20 2006

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

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