Karl Fogel wrote:
> One thought I've been having is that a feature bounty might be good,
> using a "fund and release" collective pledge system such as
> fundable.org, strayform.com, etc. (Been thinking about that for 'svn
> obliterate' support too.)
>
> Someone would have to go through the effort of scoping the task a bit,
> organizing the pledge drive, publicizing the bounty in places where
> potential developers lurk, etc. But that's not a huge amount of work,
> and it seems like you care about this issue a lot, so maybe you'd be up
> for it?
>
I've been interested in Subversion from the beginning -- like many
others, I was unhappy with the shortcomings of CVS. I've been
subscribed to every Subversion mailing list for over 7 years now (since
2/22/01). If I had been able to spare the time, I would have
participated in the development work all along, but I haven't even had
the time to keep up with reading the mailing lists! I have over 100,000
unread messages from the "dev" mailing list and over 75,000 unread
messages from the "users" mailing list on my system. I've not had the
time to keep up with Subversion on a day-to-day basis, especially since
I've never gotten around to moving from CVS to Subversion (for various
reasons). Nevertheless, I've checked in with the project from time to
time, paid attention to the evolving feature lists and release
announcements, etc.
At my workplace, we needed a version control system, and I played a key
role in advocating for Subversion as the solution. For due diligence
reasons, we spent over a month analyzing various options (Visual
SourceSafe, RCS, CVS, PVCS, Perforce, Subversion, etc.) and ultimately
decided on Subversion (which I suggested from day one). Perforce was a
close second, but the $800 per-seat cost of the system gave Subversion
an insurmountable advantage in management's eyes. At the time,
merge-tracking was the only significant feature I was aware of in
Perforce that Subversion lacked, and I understand that's coming in
Subversion 1.5 soon. Unfortunately, we've been delayed for over a year
in deploying Subversion, for various reasons involving internal politics
and competing priorities. But we're finally at a point where production
use is imminent, and I'm working on a deployment plan.
I was under the impression that Subversion had completely eclipsed the
features and functionality of CVS, and that there was nothing you could
do with CVS that couldn't be done as well (and usually better) with
Subversion. As such, I have been shocked and flabbergasted twice in as
many days to discover significant shortcomings of Subversion relative to
CVS.
The lack of an "obliterate" function was the first shock. I was aware,
years ago, that the only available option was to dump, filter, then
reload the repository. I naturally assumed this was a temporary
workaround for a complex programming problem that hadn't yet been
prioritized for development. The fact that this still hasn't been
addressed is incredible, given the solid need that exists for this
functionality, as demonstrated by several use cases that have been
detailed already. This is a serious deficiency as compared to CVS,
which offers "cvs admin -o" to "obsolete" specific revision numbers by
merging the surrounding deltas in the repository. Also, even though
it's not a CVS command, it's a trivial CVS administrative operation to
blow away a file or directory tree entirely by removing the underlying
files in the CVSROOT. But I do understand that the "virtual filesystem"
nature of Subversion's repositories makes this a seriously difficult
problem to resolve, so that does somewhat justify the fact that it
hasn't yet been implemented, but it still seems like it has been delayed
for years longer than it should have been. I can only hope it gets
implemented before we run into an inescapable need for it.
I was shocked all over again to discover Subversion doesn't preserve
file modification times whatsoever. Again, this is something that is
easily done with CVS; using the -M and -d options, CVS can use and
preserve the file modification time for each file (even as keywords are
substituted), rather than resetting the timestamps. I use this CVS
capability routinely to preserve the proper timestamps on files which I
forgot to check in. I am aware that CVS resets the timestamp on an
update for make's benefit, so I often find myself deleting the working
copy of a file AND editing the "CVS/Entries" file to remove the entry
completely, so that I can update it again and have it checked out with
its original timestamp. Even as a software developer, I consider the
timestamp to be a valuable piece of metadata that is critical to preserve.
I entirely understand that the current behavior is sometimes convenient
for "make", but that doesn't qualify this naive timestamp handling
behavior as a "feature". At best, that's a serendipitous benefit, and
really not such an important one, since you can always use "touch" or
"make clean" to force a rebuild if necessary. Besides, in reality,
Subversion's naive timestamp handling even causes problems for "make",
such as attempting to rebuild generated files (e.g. "configure" scripts)
that the local system isn't actually capable of rebuilding. It would
make more sense to argue that "make" should be smarter. Someone
mentioned that ClearCase has a custom "make" that uses version control
information in addition to timestamps. Wouldn't it be better to extend
GNU make to understand Subversion's version control information than to
punish everyone who cares about preserving timestamps for the occasional
benefit of a single development tool?
It's easy to reset the timestamp if/when it's appropriate, but
impossible to recover the timestamp after it has been permanently
discarded by the system. Yes, the timestamp is "just" metadata, but
it's critical metadata to many people (especially outside of software
development), and telling people not to care is unrealistic. People do
care, about both timestamps and obliterate functionality, and they have
good reason to care. To the Subversion developers, neither of these
issues is critical to their own needs from Subversion. If they were,
both would have been addressed before 1.0 was released. Nevertheless,
there are many users and potential users who have real needs in these
areas that can't just be rationalized away by telling people to conform
to Subversion's way of doing things. Subversion has advanced features
(like the excellent binary file support and the ability to mount a
repository as an autoversioning filesystem over WebDAV) that are
encouraging many uses for Subversion outside of software development,
and Subversion's shortcomings are largely due to hardcoded assumptions
that Subversion would be primarily used for software development. Many
people can't adapt their needs to conform to Subversion -- if the system
can't evolve to handle their needs, they simple won't use it in the
first place.
For open-source version control systems, RCS used to be dominant. It
was simple, straightforward, and did the job of tracking changes to file
contents. CVS was developed in response to shortcomings of RCS, and
became dominant in its place, as it was clearly superior to RCS.
Nevertheless, CVS had shortcomings of its own, which its developers
refused to address, such as the inability to track changes to the
directory tree. Subversion was developed in response to the
shortcomings of CVS, and is becoming dominant in its place, as it is
clearly superior to CVS. Nevertheless, Subversion has shortcomings of
its own. I hope the Subversion developers are more willing to address
these shortcomings than the CVS developers were, because I'd hate to see
this cycle continue.
I was surprised (and pleased) to discover that BOTH of these issues
(obliteration and preserving file modification timestamps) have recently
(just this month) been discussed in detail and given careful attention
and excellent summarization by dedicated supporters of each issue. I
hope this means we might see these issues resolved in the near future.
Personally, I would be more than happy to help with
design/specification/analysis work, which has been cited as a major
obstacle to implementation. I'm also not opposed (in principle) to
helping on the implementation side, but I've never looked at the source
code, so I have no idea how much of a learning curve that would involve
(and my available time is still quite limited). I realize that the
existing developers haven't found either of these issues to be "itches"
that sufficiently need scratching, but to many users, both are potential
showstoppers.
On a separate note, at the moment, I'm still trying to figure out how to
cleanly import the hundreds of backup files I've carefully preserved
(with timestamps) for many months, intending to check them into
Subversion as a reconstructed version history. I don't want to lose the
timestamp information, and I'm starting to think I may have to check
them into CVS first, backdating the timestamps, then use "cvs2svn" to
convert the repository, or perhaps to check in each file and then set
"svn:date" to the file's timestamp (is this indistinguishable from
actually checking in at that time?)... After all these years, it seems
that Subversion ought to have some better solutions available for this
situation, but I haven't found it yet. Just checking everything in with
today's date represents a major loss of the version history that I would
have if we had been using Subversion for the past year. I want to be
able to check out as of a date 6 months ago, even though we weren't
using Subversion yet. Converting legacy version history to Subversion
is still a surprisingly high obstacle to adoption, which I thought was
another problem that would have been better solved by now, especially
for existing collections of timestamped backup files, which are an
extremely common form of manual version control...
I'm not attacking the Subversion developers here; they seem genuinely
responsive and committed to doing the right thing. What will it take to
convince people that addressing these issues is the right thing, and
then to get them implemented? I'm willing to put some effort into this,
if it will be productive, but I can't afford to waste my time if it
would be a dead end...
Thoughts?
Deven
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-22 05:13:25 CET