>>>> - If you use the revision number in more than one file, you're not using
>>>> it right. Every programming language knows includes. So have *one* file
>>>> with the revision number in it, and include that wherever you need it.
>>> I have multiple projects in one solution.
>> As does TSVN. The version.h file generated by SubWCRev from version.in
>> is used in TortoiseProc and TortoiseMerge.
> The different projects are at different revisions? ;-).
Yeah, but you'll get more or less the same answers from SubWCRev if
they are in the same repository (at least after doing an update). HEAD
will be the same for all the projects.
IMHO if you need to know/track/supply info on the version number of a
file then use the subversion keywords like $Id$. If you're interested
in the version (HEAD or revision range) of a collection of files then
use SubWCRev to supply this info in a single file, build from a
template file at some convenient moment (IMHO as a pre-build step).
Put version control on the template file and svn:ignore the generated
>>> The amount of effort to use SubWCRev just keeps going up and up and up...
>> I don't understand what's so much work.
> Well, it's just my opinion.
> And I can see how it's not any kind of work for you since you know the
> tool inside-out and you only use it in one single project.
> I'm thinking of putting it into use in more projects, with users that
> doesn't know the tool and it's quirks.
It is always dangerous to let people handle tools they don't
understand. At some point they will start shooting themselves and
others in their feet ;)
> Anyway, what I'm thinking is:
> - high learning curve compared to the relatively simple thing it provides
> - takes a little too much work to set up for each project for one to
> bother learning it
I'm not a VS.NET user myself, but can't you create a template project
including the pre-build SubWCrev stuff and use that instead of a new
empty project. I think most IDEs support this sort of customisation.
> - requires that you educate users needlessly on how to integrate into
> their projects
> I think the above wouldn't be necessary if there was an option to do
> keyword-expansion (in a sane way) instead of keyword-replacement.
Only subversion keyword expansions are done without triggering the
'modified' status of files. I don't know of any way to modify a file
outside of subversion without letting subversion think the file has
changed (and if there is such a way that would create quite a loophole
wouldn't it :)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Apr 10 15:02:16 2005