John Burwell said:
>>
On Aug 29, 2006, at 12:34 PM, Steve Fairhead wrote:
> However: any time I do anything as drastic as checking files out of a
> VCS, or reverting, or including a replacement file from a colleague,
> or otherwise messing with the data that make uses to do a build, I'd
> expect to do a make clean or a touch.
>
> This is pretty basic stuff. It's not a reason for a VCS to throw data
> (in the form of timestamps) away.
For what it's worth, I likewise hate seeing information destroyed. Is it
really up to SVN to accommodate make's behavior in protracted what- if
scenarios?
<<
Well said. Seems to me that SVN's behaviour is defended here as a workaround
for a problem that exists in collaborative s/w projects with/without a VCS
system.
(To the multitudes who pointed out my misunderstanding of Alice's part in
the example scenario earlier: yes, it's a fair cop, I did misunderstand.
However the problem still exists if you take the VCS out of the picture. If
a colleague gives you a file that predates your last build, you'll have to
let make know somehow, whether by touching the file or doing a make all.
It's nowt to do with the VCS.)
>>
SVN is useful for all kinds of projects and document-management
applications. I could make sense out of a checkout/update option that uses
the check-in date as the last modified date on checked-out files, but a more
intuitive default would be to preserve the file exactly as it was
checked-in, which would include available metadata.
I'd like to see date clobbering provided as an option for users who spend a
lot of time dealing with the issues presented by make. The length and
verbosity of the discussions on this list is clear enough evidence that
people without an understanding of the make problem and its variants will
likewise have no understanding of SVN's current default date-clobbering
behavior. If SVN is to continue being promoted as a tool of versatility and
flexibility, supporting the most general use cases by not clobbering file
modification dates would be best, while allowing users with more specific
requirements to take advantage of the options as needed would maintain SVN's
convenience.
If nothing else, the behavior and its reasoning ought to be explained in the
documentation so that it comes as no confusing surprise while users are
attending to development outside of a make environment.
<<
Again, well said, and worth repeating.
Yes, there are problems with makefiles in group projects. It's not up to a
VCS to work around them. And a VCS is more generally useful than in just
those environments.
Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 23:45:50 2006