> > 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.
>
> There's really not a lot to learn. Use the doc, Luke.
>
> > 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
>
> learning curve? What's so difficult about having a template file?
>
> > - takes a little too much work to set up for each project for one to
> > bother learning it
>
> Not more work than any external tool you use as a pre/post-build step.
>
> > - requires that you educate users needlessly on how to integrate into
> > their projects
>
> That's a moo point. You always have to tell users how to use a tool. No
> matter what tool it is. And if people don't know how to integrate tools
> in VS.NET, then you have to tell them that too, no matter what tool it is.
Telling users that putting 'MagicRevTool.exe --update' in the
pre-build step will solve their problems and update their keywords
correctly is easier than what's currently needed by about 5 light
years.
(Joke! :-). It's not really *that* bad.)
I'm just saying this (quoted above) because I know that we have a
whole bunch of projects; in differing build environments; where we
should really be using the sort of tool that SubWCRev is. But we're
not, and as I see it the main reason for that is that it's troublesome
to get to work correctly, so people just settle for
$LastChangedRevision$ or type in version numbers manually.
> > 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.
>
> Subversion already does keyword expansion. So why should SubWCRev copy that?
I'll answer that with a spiffy remark, if you don't mind.
Arch already does versioning, so why should SVN copy that?
> > 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$ */
>
> If SubWCRev would do that, then you either can't have the file under
> version control, or the file would be modified after every build and be
> in the committed list. So users would constantly commit a file with no
> 'real' changes in it.
Yeah, not exactly pretty, the file with the version in it would suffer
extra commits *shrugs a bit*.. Not exactly important in my
environment, the modified file would just go in along in the same
commit as the build, so everybody knows what it's about..
> > 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.
>
> No, it's as user friendly as it can be. It was designed to do exactly
> what it does. You want a different tool, and you use SubWCRev in a way
> it never was designed to work. That's why you think it's not user
> friendly. If SubWCRev would work as you want, we couldn't use it in
> TSVN. And it wouldn't do what it was designed to do.
Our opinions obviously differ. As I said, I'll hack at it a bit.
Maybe I'll come to the same conclusion as you, maybe I'll think I've
made it prettier and userfriendlier. I could let you know at that
time, if you're interested.
> > #define tuggummi 123 /* $WCREV$ */
>
> That could work for C files, but how does SubWCRev know what a comment
> looks like in other languages? And what exactly is it replacing? And
[snip]
> As far as I can see, what you propose is not only harder to program but
> also harder for the user to get working reliably.
Ay! It was only examples for the purpose of the examples.
It wasn't a proposal, nor anything I was realistically looking at implementing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Apr 10 00:27:19 2005