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

Re: D10 + Pre-Build hook

From: <rosenfield_at_users.sourceforge.net>
Date: 2007-09-05 13:55:06 CEST

Stefan Küng wrote:
> > Whoever wrote SubWCRev really need to fix it so that it will
> > just replace the revision number in existing files instead of
> > requiring a pair of old+new files.
> It doesn't need to be fixed. It's not SubWCRev that's broken
> but your understanding of version control. If it would modify
> an existing file under version control, that file would always
> show up as modified and get committed every time. That's
> not good, and not wanted.

It would not, surely. Of course, Subversion needs to be told
that it's a keyword and that it should ignore it. This already
happens for $Revision along with a myriad of other keywords,
so it's hard to imagine that this simply would not work for one
particular new keyword.

(Even _if_ it was that inflexible, there's always the option of
 piggy-backing on an existing keyword, fx $Revision.)

> > I can fix SubWCRev if you want, but please don't break stuff
> > just to satisfy the requirements of a poorly designed tool.
> Sorry, you can't fix what's not broken.
> And please think first before you call something 'poorly designed'.

Apologies, did not intend to hurt anyone's feelings. I just meant
that it's a broken design when used in combination with an IDE.

> > SubWCRev seems designed for unix makefiles where a temporary file can
> > be created just for the purpose of compiling and then removed again
> > afterwards. It's just plain crap when used together with a good IDE.
> SubWCRev only runs on windows. Does that give you a hint?

So does make, nmake, etc. Reverse hint ;-).

> And again, *think* before calling SubWCRev crap.

I did not call SubWCRev crap. I called the outcome of a particular
solution designed with the use of SubWCRev (as it is now) "a crappy
solution". (At least that's what I meant to say!)

> (I could do the same with your "good" IDE).

BDS has it flaws. It crashes from time to time, and it is a CPU hog.
Be my guest.

> > Let's just fix SubWCRev so it works with strings, just as $Revision.
> I wonder if I should just tell you to modify SubWCRev to your needs?
> Would be funny to watch you deal with all the broken working copies,
> broken builds, ...

No need to tell me, I intend to already..

> > We can't make it run automatically on 'svn update' and 'svn commit'
> > unfortunately, so we'll still have to put it in the pre-build
> > commands for various IDE versions and the build .cmd. I guess
> > that's OK, we need to have something there anyway in order to
> > get the "has local modifications?" flag correctly into the source
> > code and the final executable.
> If you want a clean, *working* solution, then do what TSVN does
> (and all other projects which like something that works): use a
> template file which gets 'copied' by SubWCRev to a file that is
> then included in your project.

As I originally argued, that's a highly broken solution..

> Usually, you will need such template files for all the stuff which
> needs local/absolute paths anyway.

There's not a single absolute path in either the project IDE files nor
the project build files, AFAIK.

> > I'll take a look at fixing SubWCRev. I think it's GPL, so we can
> > include the modified version in our repository under 'extra'.
> Once again, you can't fix what's not broken. Good luck trying though...

Thanks. I take it that you don't want to see patches ;-).

To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Sep 5 14:14:54 2007

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