> > For example I want to hook SubWCRev in as a Pre-Build event in Visual Studio.
> > If I want to integrate SubWCRev with the VS integrated build system as
> > it is now, I'll have to make some abomination of scripts that on
> > pre-build runs a SubWCRev and moves some files around to replace the
> > original source file with the SubWCRev replacement, and when the build
> > finishes move the files around again. *If* the build finishes. And
> > I'll be really mad when it doesn't and I have to go through all my
> > source files and replace back numbers with $WCREV$ and such :-).
> > Especially if I've missed that the post-build script didn't run for
> > some reason, and I've later modified a lot of code and checked in and
> > compiled and released. Then I'll be mad.
> You should use SubWCRev the same way TSVN does: use a template file
> which then you can create the file you use in VS.NET from.
> We had SubWCRev as a pre-build step in the TSVN build process too. But I
> removed it from there and put it in the batch file because I sometimes
> don't want it to run everytime I build the project.
So you want me to have duplicate copies of every source file in my
project that I want SubWCRev to process? One that's the template that
I'll edit, and one which will get compiled.. I'd have to open the
template also in VS.Net in order to edit it, but I can't have in
included in the solution because VS.Net would try to compile it and it
would clash with the "destination" source file.
- I'd loose all the benefits of Visual Studio, specifically there
would be no class completion and such.
- I'd loose synchronization with the other developers, because the
template file is not in the solution file but in my "personal user
preferences of what files should be open in the editor", eg. the .suo
- 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).
- I have to live with, half the time, somebody opens the solution,
Visual Studio automatically removes the non-existing source file (they
haven't run SubWCRev yet) from it, and they commit changes they made
to something that does exists or another project. The entire solution
gets commited and suddenly the source file is missing from it.
- Other times any of the other developers might misunderstand and
submit a modified destination file instead of the template, in which
case that will have to be sorted out.
I could probably go on, but I think I have enough examples for now as
to why that's not such a pretty solution.
> > Seeing as this is a good thing to do on all your projects, it would be
> > very neat if SubWCRev could be made to just modify the original source
> > files, with a single command like "SubWCRev --update", and all that
> > one had to remember would be to put "SubWCRev --update" in your
> > pre-build event in all your projects.
> How would that work? I mean it replaces the keyword, that means after
> SubWCRev ran, the keyword is gone. And that means you couldn't run it
> again on the same file.
The above was of course assuming that SubWCRev could be told somehow
to keep the keyword in place.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Apr 9 22:26:14 2005