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