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

Re: Feature request: Keyword $Rev$ with a twist

From: Mats Nilsson <mats.nilsson_at_xware.se>
Date: 2002-08-05 15:34:45 CEST

At 13:01 2002-08-05, you wrote:
>On Mon, 2002-08-05 at 07:40, Mats Nilsson wrote:
> > The trouble of doing a combination of 'svn info' and 'sed' to patch the
> > source code as a build step, is that svn will not recognize these changes
> > as simple keyword substitutions. It will think that the file has changed,
> > even though it hasn't (in a logical sense), and the file will get checked
> > in in a changed state, upset merges and diffs and whatnot.
>For what it's worth, I'm perfectly happy with the file being generated
>from a script as part of my source-release procedure. This is what
>happens with your ./configure script, after all - when you create the
>source release, you run autoconf/automake/etc to create it. The file
>need not be placed in the svn repository at all, just as ./configure

While this is fine in performing work in a single homogenous environment
I'm concerned about:

1. Building directly from an 'svn export'ed distro. ./configure will
    not have access to 'svn info'. If the file is in source control and
    is checked out with correct version info, then the build process on a
    remote machine wouldn't have to guess ;) what version number to write
    in the source file.

2. cross platform development - finding a simple solution that works both
    from a *nix Makefile as well as in a MSVC environment. Having read the
    svn dev list for a while, I know that the build process on svn itself
    has presented some interesting hurdles related to keeping the MSVC part
    up and running. Maintaining different sets of tools/scripts is always
    more difficult than maintaining one set.

3. Users on MSVC that are used to check out the source and fire up their
    IDE. Even if it is acceptable to have a build script for the nightly
    test environment or release preparation environment, the stuff must
    still build without extra tool invocations for average joe. Therefore
    I'd prefer to have a default version.h checked in, which may or may not
    be updated automagically by svn or other tools.

4. Keeping the version.h file up to date when 'svn up'. I understand
    that it can be tricky to implement this in svn. But it will surely
    become even more tricky to implement this outside svn. And it needs
    to be implemented for each project that would use this.

5. Those who think I'm insane wanting a $WorkingRev$, but still considers
    extracting the $LatestChangedRev$ from the project directory and piping
    this into version.h. I'm concerned that they will run into related
    problems these problems too.

Thanks for your time.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 15:43:19 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.