thanks very much for response!
> > I'd like to stress this stuff - it would be _very_ usefull in
> > automated builds environment (like ccnet.sf.net). Those
> > could have alot of "build artifacts" that is unversioned files but
> > have to begin with clean copy.
> The fact that you are referring to those files as 'build
> artifacts' should have given you a clue it might not have to
> do with your version control tool.
> > Should we leave cleanup for makefiles? No - we are suppose
> to prepare
> > clean environment for builders.
> Again, you indicate it has to do with building, not with
> version control.
I have to agree with you. From architects view it is indeed more builder
stuff than version control.
But - alot of others version controls support this (even CVS) so SVN support
would be nice. Also - it is pretty hard to solve this problem for all
possible source controls and builders, becouse we dont know anything about
any side. Since builder could fail at any moment and leave some "artifacts"
anywhere, action have to be taken either in our code or in source control.
So far, we rely on source control - via fresh checkout on SVN or clean copy
on those scs which supports it ("-q update -d -P -C" on CVS).
> > Delete all+fresh chekout is _very_ costy operation and "svn revert
> > -R;svn update" works only sometimes.
> Maybe you should create an out-of-tree build, or export a
> tree from your working copy and build there. Blow it away
> when your build is done. Did you know you can export working
> copies (ie without contact to the server)?
No - I dont! I just test it and indeed - it is better than fresh checkout!
Still - we have to have 2 copies of whole repository, which could be alot in
some scenarios. Also big repositories take time to copy even that it's
usually better than fresh checkout.
out-of-tree build: it would be nice. Unfortunatelly, we coudnt force builder
to do this, since we support generic build which could do anything. Mostly
it just do its stuff inside of wc. Nice builders clean up after work but we
coudn't count with it.
> In our case
> > (automated environment) there are no files, which should be
> I hate to tell you this, but this is not the use case for the
> majority of working copies...
I agree - not majority of working copies. But, IMHO, very needed ones. As
Continuous Integration becomes more common practice, this will be important
for even more people.
> I'm having an extremely hard time thinking of a good reason
> why this belongs in a version control tool. I can't find any.
> I'm sorry.
I hope, I gave you one.
> I'm sorry if this mail is a bit harsh, but I hope the
> export-for-working-copies does help you a bit...
No problem :) Thanks for your time!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Mar 21 18:46:28 2005