Peter N. Lundblad wrote:
> Ivan Zhakov writes:
> > I really don't understand why we should support these old working
> > copies because they created BEFORE 1.0 was released. So we shouldn't
> > support it, if understand our compability policy correctly.
I agree that we don't NEED to support them, but see below. (Our compatibility
policy may say that we do not need to support them, but it never says that we
should not (ought not to) support the old ways.)
> Well, if people agree we don't need this compat hack, I'll not bother.
I have been using my main Subversion source working copy continuously since
those olden days, and today "svn commit" choked on one of the old checksums
when committing a file that hasn't changed since then
(notes/fs-improvements.txt). I have been encountering another such file once
in every few months since whenever the support for the old style was dropped.
"commit" and "revert" are the only two operations that I have noticed failing
on these old files. I'm not sure whether any other operations explicitly
support old-style checksums, or if other operations just don't look at them.
My work-around is to temporarily save and remove the local changes, then update
the file to r0 (thus deleting it) and then to HEAD (thus getting a new-style
checksum), and re-applying the local changes. I think it's perfectly
acceptable to have to do something like that once in a while for someone who
has kept a WC around since way before v1.0.
> OTOH, there was no upgrade path in this case and adding two lines to be
> friendly doesn't seem too much:-) I really don't have a strong opinion here.
If the whole of Subversion (commit, revert and all other operations) can
support those old checksums with just a few lines of compatibility code, I'd
say make it compatible, because we know we do have some users who started
before v1.0 and providing a smooth upgrade for users is a very important factor
in their overall impression of the software. However, there are rather few of
them and they know that pre-1.0 incompatibility is acceptable, so if it
involves any more than a few lines of code (to support it throughout the code
base), strip it out.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 19 00:26:02 2006