Re: base64 encoded md5 digests in entries file

[Julian Foad <ju...@btopenworld.com>]

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

Re: base64 encoded md5 digests in entries file

["Peter N. Lundblad" <pe...@famlundblad.se>]

Julian Foad writes:
 > Peter N. Lundblad wrote:
 > > 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.

Oh, so this means that we've already dropped part of this support
earlier. Well, then my recent commit didn't actually make things worse.

 > "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 

Another workaround should be to just remove the ckecksum attribute
from the entries file, because that's optional.

I'll not do anything about my commit in svn_wc_transmit_text_deltas2
until we decide to reintroduce the compat hack, but since this seems
like more work, I don't think it is worht it.  I agree with Zhakov, it
starts to be time to drop pre-1.0 compatibility hacks.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org