Re: [PATCH] provide advance warning of some future pack default changes

Nicolas Pitre [off-list ref] writes:

On Mon, 17 Dec 2007, Junio C Hamano wrote:
...

quoted

Instead we unconditionally said "if you are downloading with the new
client, we assume you would never be using older client to access that
repository locally, if you did so, you are screwed."

IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
native protocol use offsets to delta base when possible) could have been
a bit more careful in this respect.

Probably.  But this can hardly be called a "corruption" since nothing 
was actually lost, rather an incompatibility problem.

It is not a corruption, but the distinction doesn't matter much to the
end user who wants to get the job done with the data right now.  The
data that was made inaccessible is inaccessible.  The only difference is
that it is recoverable once the user upgrades, but that may be painful,
even though it may be rewarding afterwards and worth doing so, and the
user may not be able to afford doing so right at that moment.

On Mon, Dec 17, 2007 at 04:41:19PM -0800, Junio C Hamano wrote:

It is not a corruption, but the distinction doesn't matter much to the
end user who wants to get the job done with the data right now.  The
data that was made inaccessible is inaccessible.  The only difference is
that it is recoverable once the user upgrades, but that may be painful,
even though it may be rewarding afterwards and worth doing so, and the
user may not be able to afford doing so right at that moment.

Junio, I agree 100% with your description here. This is all about user
experience and data which is silently made inaccessible makes them feel
pretty bad.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com

On Mon, 17 Dec 2007, Junio C Hamano wrote:

Nicolas Pitre [off-list ref] writes:

quoted

On Mon, 17 Dec 2007, Junio C Hamano wrote:
...

quoted

Instead we unconditionally said "if you are downloading with the new
client, we assume you would never be using older client to access that
repository locally, if you did so, you are screwed."

IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
native protocol use offsets to delta base when possible) could have been
a bit more careful in this respect.

Probably.  But this can hardly be called a "corruption" since nothing 
was actually lost, rather an incompatibility problem.

It is not a corruption, but the distinction doesn't matter much to the
end user who wants to get the job done with the data right now.  The
data that was made inaccessible is inaccessible.  The only difference is
that it is recoverable once the user upgrades, but that may be painful,
even though it may be rewarding afterwards and worth doing so, and the
user may not be able to afford doing so right at that moment.

Sure, but at some point that's something users mixing versions should be 
ready to cope with.  We try to make it as painless as possible of 
course.

Data corruption is usually something you just cannot recover from 
(unless you have backups).  And if mixing different tool versions 
actually cause data corruption then this is a much much more serious 
issue and that must be avoided.

So at some point the distinction must be made, and if using an old 
version of Git on a repo created by a new version actually produces data 
corruption as Joel seemed to imply, then we must really take it 
seriously.  OTOH, compatibility issues are usually much less of a pain 
to fix.


Nicolas

On Dec 18, 2007 4:23 PM, Nicolas Pitre [off-list ref] wrote:

Sure, but at some point that's something users mixing versions should be
ready to cope with.  We try to make it as painless as possible of
course.

I have to say I agree with the "apparently minor updates should not
break cross-version compat". And I think it's a communication issue
around the version numbering. The fact that this will be introduced
with a v1.5.5 is, IMHO, a good part of the problem.

If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
revisions should interoperate with end users not even thinking about
it. But 1.5.5 has in its changelog lots of deprecations and interop
changes.

It's not good communication to label it 1.5.5.

Other than that, it's an _amazing_ thing, and I'm in love with git.
But the version number is a bit of a lie -- and is bound to confuse
and anger end users.

cheers,


martin

On Tue, 18 Dec 2007, Martin Langhoff wrote:

On Dec 18, 2007 4:23 PM, Nicolas Pitre [off-list ref] wrote:

quoted

Sure, but at some point that's something users mixing versions should be
ready to cope with.  We try to make it as painless as possible of
course.

I have to say I agree with the "apparently minor updates should not
break cross-version compat". And I think it's a communication issue
around the version numbering. The fact that this will be introduced
with a v1.5.5 is, IMHO, a good part of the problem.

If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
revisions should interoperate with end users not even thinking about
it. But 1.5.5 has in its changelog lots of deprecations and interop
changes.

It's not good communication to label it 1.5.5.

I agree.  Might be time for 1.6.0?


Nicolas