Marcus Rueckert writes:

On 2007-09-26 19:51:30 +0200, Christian Boltz wrote:

...

on Mittwoch, 26. September 2007, Susanne Oberhauser wrote:

...

I just updated the svn file property to actually update the Revision string, as I hoped the next release should at least have a meaningfull svn revision in it:

...

Then I realized this string will only be updated when this very file changes.  Hmmm.

What about using the output of svn info |grep Revision

wrong approach. svn trees can have mixed revisions. http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in...

the correct approach is described here: http://subversion.tigris.org/faq.html#version-value-in-source

darix

thx for the pointer. Hmmm... That then needs a svn co instead of a svn export in the tar ball, though. I'd rather prefer to have the whole source package in svn and collect all files that are needed in some script. Like a 'dist/' subdir in https://forgesvn1.novell.com/svn/opensuse/trunk/buildservice, in there the extra files you need for distribution and packaging, for starters all the files of the package, plus some Makefile somewhere that runs a svn export and extracts the revision from the output and then wraps all that's needed to a source_rpm. A buildservice/documentation/common/xslt/common/de.xml A buildservice/documentation/common/xslt/common/l10n.xml Exported external at revision 313. Exported revision 2265. Wether this helps or not depends on how we want to manage the build server deployment / 'maintenance' of the obs-* packages going forward. I'd personally prefer to have a working copy checked out in svn, work on that, do my builds locally from a directory in there (containing the spec file and some more), update that locally built package and once everything works upload the working dir to the bs. This approach is using the priviledge of being the maintainer of both the code and the package. Alternative is to do as if the code maintainers and the package maintainers were not the same: work on the package until it works for distribution, then integrate the changes and add-on files to the svn, then adjust the package for that, having parts of what you need manitained with osc or such and parts of it in svn. We _can_ do that and we do it right now. S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business Partner Engineering Maxfeldstraße 5 developer.novell.com 90409 Nürnberg SUSE LINUX GmbH, GF: Volker Smid, HRB 21284 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org