Joel Becker <Joel.Becker@xxxxxxxxxx> writes:
> On Tue, Sep 11, 2007 at 02:05:34AM +0200, Wincent Colaiuta wrote:
>> But that's precisely the group release notes are for; existing users who
>> need to be informed of any changes to the way things work.
>
> No one reads the changelogs of 100 packages updated via "yum
> update". Heck, they don't even see the list of packages. They just
> switch to a different desktop while it runs.
Distros are not something under my control, so I cannot help you
much there.
> 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;
- you cannot afford to write something to the repository to
mark the latest version that mucked with the repository every
time any operation happens;
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.
After reviewing Release Notes for v1.5.0, I do not think we
could have done much better, unfortunately.
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.
Specifically, the available options are:
- There is a configuration variable core.legacyheaders that
changes the format of loose objects so that they are more
efficient to pack and to send out of the repository over git
native protocol, since v1.4.2. However, loose objects
written in the new format cannot be read by git older than
that version; people fetching from your repository using
older clients over dumb transports (e.g. http) using older
versions of git will also be affected.
To let git use the new loose object format, you have to
set core.legacyheaders to false.
- Since v1.4.3, configuration repack.usedeltabaseoffset allows
packfile to be created in more space efficient format, which
cannot be read by git older than that version.
To let git use the new format for packfiles, you have to
set repack.usedeltabaseoffset to true.
The above two new features are not enabled by default and you
have to explicitly ask for them, because they make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason. We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native clients can
still fetch from a repository that packed and pruned refs
(the server side needs to run the up-to-date version of git),
but older dumb transports cannot. Packing of refs is done by
an explicit user action, either by use of "git pack-refs
--prune" command or by use of "git gc" command.
So everything was opt in and clearly marked as such. You may
not have read it, distros may not have shown it, but then that
is something we cannot do much about, unfortunately.
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.
-
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
