On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Dec 2007, Joel Becker wrote:
> > You may not see a case for actual corruptions, but my coworker
> > updated his tree on a box with 1.5.x, then tried to work on a box with
> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > unusable. He had to re-clone, and I think he got lucky recovering
> > pending changes (probably using 1.5.x on the branches with the changes,
> > as master was what got broken).
>
> I still claim that there wasn't any corruptions.
>
> Just for fun, just edit some document with Microsoft Office 95, then
> open the same document with Office 2007 and save it with default
> settings. Now try to open it back with Office 95. It won't work.
> Does that mean that the document got corrupted?
No, but when you try to re-open it with Office 2007, you expect
it to work, don't you? His master was messed up even for 1.5.x. It was
now months ago, so I don't quite remember all the details, but I think
you'd agree that "1.5.x no longer works" is not correct.
> I'm telling you that there won't be any such corruption. Just like in
> the M$ Office case, it is expected that newer versions make data
> unusable by older versions at some point -- that's the inevitable side
> effect of progress.
Sure, we're not complaining about that. We complain some about
the fast pace (at the time he had his problem, 1.4 installs were not
unusual, and Junio's response suggested that "I use NFS" wasn't strongly
considered as a use case), but more we complain about the obscurity of
the reason. If it's obvious what happened (not the specifics, just
"please upgrade" or "repository format changed" or something), the user
moves along.
> And we cannot always anticipate what kind of incompatibility will be
> worth making in the future, so it is hard to come with proper error
> messages in all cases today.
How hard is it? We have core.repositoryformatversion. We
undoubtably have headers on our files. As an example, an older version
should be able to ascertain 1) this is a pack file 2) I don't know how
to read it. Thus, it should always be able to tell the user as such.
This is different from reporting "invalid pack file" or "corrupt pack
file", or "garbage in tree". Filesystems, as an example, set
compatibility bits or version levels. When an old kernel tries to mount
it, it does not say "corrupt filesystem", it says "this filesystem has a
feature I don't understand, I'm going to be nice and not do anything,
please upgrade". This is clear, even though the older kernel doesn't
have any specifics about what the new feature is.
> So I don't see how we could do better in that regard. Carving the
> repository format in stone to keep ancient versions working forever is
> _not_ a solution.
Once again, we're not asking for that. We're asking that you
think ahead to what can change, and plan for it, so you can tell the
user. If the user has a clear idea where to go next, the can solve the
rest themselves.
Look, not everyone reads this mailing list. No one outside of
this list reads the Release Notes. They get their upgrade via yum or
apt-get, along with 100 other packages. You can't assume that 3 months
of feature discussion here is going to be known to your average user.
Joel
--
"Vote early and vote often."
- Al Capone
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@xxxxxxxxxx
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
