>>> - 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? ;-).
>> 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.
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
- 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.
>> I'm not saying this can't be done, I'm just saying it could be done in
>> a much easier-to-use, shallower-learning-curve, less-complicated,
>> overall prettier way.
>
> I don't think so. Either you do it the SubWCRev way with template files,
> or you do it the Subversion keyword way and have a lot of coding to do
> to parse the strings. And some things won't even work because you can't
> parse the string before use (e.g. in resources).
We're getting theoretical here.
But they're not mutually exclusive.
SubWCRev could easily be made to replace keywords "the subversion way"
and still fill in the role that it has just fine. It could also be
made to do keywords in a new way where it replaces the word before /*
$WCREV$ */, so you could type:
#define tuggummi 123 /* $WCREV$ */
...And SubWCRev could replace contents in the original file, keep the
keyword, and your defines would work. SubWCRev could even be made to
accept some form of a regular expression and replace custom keywords
in files formatted in any bizarre fashion that a user may see fit :-).
It's sort of out of the scope of the discussion though, because the
specific way that SubWCRev does keyword replacement doesn't relate in
any way to the (very nice) functionality that it provides. There's no
dependency there.
>>>> - I'd have to answer to them why VS.Net complains about missing files
>>>>when they check out the source code and open the project (it's because
>>>>you have to run SubWCRev to make the files exist).
>>>
>>>If you add SubWCRev to the pre-build step, then VS.NET won't complain
>>>about missing files.
>>
>> No.. Chicken/egg, the pre-build wont run before you build, and you
>> can't build without opening the freshly-checked-out project first.
>
> And why wouldn't it be possible to open the project?
I was wrong about this point.
VS.Net complains on open if some files are missing, but it doesn't for
.h (and possibly other individual source) files. My bad, sorry.
> Please, before you say anything more,
Oops.
Anyway, you're right, this discussion has gone far, far beyond what I
intended and what the original questions bargained for.
I've got questions answered, thanks a bunch to you and Simon!
Let's wrap it up :-).
I think that SubWCRev is done in a much less user-friendly manner that
it could've been, you think it's fine the way it is. Conclusion:
I'll go modify it myself before I put it into large-scale use here.
> have a look at how TSVN uses SubWCRev.
Thanks, I'll surely take a look.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 23:32:29 2005