> * Version control is typically used for code. Having timestamps
> touched by 'svn update' solves the 90% use-case of causing programs
> like 'make' to rebuild exactly what has changed. This is a useful and
> important default behavior.
...
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
We had a discussion about this in IRC a few weeks back. I said I'd outline
two usage cases where the svn approach falls down in mail, so here it is.
First, while revision control is about code, its not always about code
*that you author*. Many companies, like the one you work for, have large
parts of their source trees coming from external vendors. In the case where
that vendor source is open source software that uses autoconf and automake,
the filestamp thing is a real issue (in either normal or use-commit-times
case). automake injects rules into the Makefile.in files that will cause it
to re-run the autoconf/automake/libtoolize programs if it detects that
configure.ac is more modern than configure, or if a Makefile.am is more
modern than its corresponding Makefile.in. Thus, if I check in (for
example) a copy of the gcc tree exactly as it was in a release tarball,
every system that I build that tree on will produce potentially different
results, because each system could have slightly different versions of
autoconf / automake etc installed. This makes reproducing exact replicas of
builds all but impossible.
Second, even though my source code may live in a revision control system, I
work with that source code in a filesystem. I would expect normal
filesystem tools like find to work correctly and give me meaningful
results. With the svn approach, I cannot rely on things like "find . -newer
foo.c" and have it return anything meaningful. While I may be able to
extract similar information from svn, I shouldn't be forced to.
File metadata is as important to many developers as file contents. If I was
a developer using rcs,cvs, sccs, pvcs, clearcase or Perforce, which can all
keep track of timestamps, I would find the lack of timestamp support a
prohibiting factor in chosing svn as a replacement. At the very least, if I
had any sort of build process that kept track of things using filesystem
data, I would be hampered by svn and may have to do a lot of work to
replicate that data. While the "some other SCM does it this way" argument
never seems to sway anyone on the SVN team, perhaps the "ALL other SCM's do
it this way" argument will.
Other mails in this thread pointed in the direction of a "metadata" branch.
I would strongly urge you to consider making this, or something like it,
the default. From my own personal experience, in two companies now, I have
not been able to move to svn due to exactly this issue.
Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-18 16:23:06 CEST