On Mon, Sep 10, 2007 at 07:27:34PM -0700, Junio C Hamano wrote:
quoted text
> 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.

quoted text
> > 	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".

quoted text
>  - 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.

quoted text
> 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.

quoted text
>     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.

quoted text
> 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@oracle.com
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html