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

Re: [TSVN] SubWCRev update

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-04-10 00:25:40 CEST

> > 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
(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
> 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

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.