Ben Collins-Sussman wrote:
>
> Subversion is not designed to "create a perfect snapshot of every bit of
> data and metadata that can possibly exist". It versions pathnames and
> directory contents. It also versions metadata, but only metadata that
> *it* considers relevant: the last time a file was committed, by whom,
> and so on. It makes no promises that its own metadata will conceivably
> cover and capture every bit of metadata in existence on every filesystem
> implementation. By your argument, I suppose it's also not very "windows
> like" to lose ACL metadata when importing files into Subversion.
>
As written before, I can live with the commit date.
But for large (maybe commercial) projects it might be necesseray
to make sure that some code is accessable by just a restricted
number of developers, e.g. the proprietary testcase provided by a
customer.
>>
>>Who said that make works better if SVN breaks the modification
>>date of all files? Don't you assume here that the make target
>>(e.g. a library or a lex header file) is not checked in? This
>>would be a very severe restriction.
>
>
> That's a pretty universal assumption. Almost anyone you ask will agree
> that versioning derived objects in a CVS or SVN-like system is a *bad*
> idea.
Talking about interoperability: It might be necessary to checkin
the files generated by lex and yacc to make sure that the same
parser is used on all platforms, for example. And if your
version control system allows you to manage write permissions,
then an unwanted update will fail with an error message.
> Clearcase is the exception, because it has its own build tools
> and actively encourages the sharing of derived objects.
I am not talking about winking in derived objects. Its a horrible
feature.
> CVS and SVN
> assume that a standard build tool like 'ant' or 'make' pay attention to
> timestamps. When you run 'svn up', you want 'make' to just do the right
> thing.
>
Surely you are right for 99% of all make targets. Maybe make
should become more clever in target evaluation.
Many thanx
Harri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 10 08:16:58 2004