On Mon, Sep 10, 2007 at 07:27:34PM -0700, Junio C Hamano wrote: > Distros are not something under my control, so I cannot help you > much there. I'm not asking you to ;-) This is about real world usage, not how to make Junio's life difficult. > > Then there's the user that doesn't administer the system. They > > don't even know the version changed. It Just Breaks, and they don't > > know why. > > That's a valid concern, but I am not sure how you would want to > address that issue. Design constraints are: > > - you cannot change the old software that is not updated on the > user's box; No, but software can be written to know how to determine it is too old and fail. eg, a protocol often has a version in the header so that older software says "I don't know it". > - you cannot afford to write something to the repository to > mark the latest version that mucked with the repository every > time any operation happens; Of course not, nor would I advocate such. When it comes to "new version changed something that an old version won't understand", that's the only time you'd have to write out a flag. People making this change to the software had better be aware that they have added this incompatibility, and as such can be aware to mark it. > We _could_ check presence of $HOME/.knows-git-version-X.Y.Z file > every time we run (that's just a single stat(2) call that cannot > be too expensive) and if there isn't one, ask the user if he has > read the release notes and understood the backward compatibility > issues if there is any, and refuse to run until getting a > satisfactory answer. > > But I personally do not think that would be an improvement. Nor do I. I'm *still* not asking that we find a way to annoy the user into reading the release notes up front! I'm asking that when something behaves unexpectedly, and the user goes to find out why, the answer is where they look. If "git foo" does something different, and appears to have broken, the user isn't going to assume "it changed", they're going to assume they did something wrong. They're going to look at git-foo(1). And somehow, even as a tiny, one-line "X changed x.y -> x.y+1, see the release note", git-foo(1) should mention that they didn't do something wrong. > As of git v1.5.0 there are some optional features that changes > the repository to allow data to be stored and transferred more > efficiently. These features are not enabled by default, as they > will make the repository unusable with older versions of git. We didn't select any of these. This sort of behavior is a good thing. There is no "silent change" or surprise, because you have to opt-in. This clearly wasn't the problem. > I think there was _one_ honest slippage though. Fetching from > 1.5.0 peer by 1.5.0 client could (after doing content > negotiation between both ends as a protection measure) create a > packfile that cannot be read by older 1.4 clients. Obviously > you cannot expect that kind of "protection" to work across set > of machines with mixed versions sharing a repository over NFS, > and that probably is a mistake we can learn from. I suspect this is what corrupted our repository, as it would create packs the older 1.4 version wouldn't see (and perhaps complain about). Here's where the 1.5 client says to itself "I know I'm about to create a packfile that older versions can't handle, I'd better mark something to tell older versions to give up." Isn't this what core.repositoryFormatVersion is for? Joel -- None of our men are "experts." We have most unfortunately found it necessary to get rid of a man as soon as he thinks himself an expert -- because no one ever considers himself expert if he really knows his job. A man who knows a job sees so much more to be done than he has done, that he is always pressing forward and never gives up an instant of thought to how good and how efficient he is. Thinking always ahead, thinking always of trying to do more, brings a state of mind in which nothing is impossible. The moment one gets into the "expert" state of mind a great number of things become impossible. - From Henry Ford Sr., "My Life and Work" 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
