upgrading GIT from version 1.7.0.4 to 1.7.6.1.

upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Mikaël]

Dear All,

I am working for a company where several hundreds of people are working with
GIT ; in other words, GIT is a central tool for us since our working
processes are based on it.

Today, it is the time for us to upgrade from version 1.7.0.4 to 1.7.6.1 (the
latest stable).
It is important for us to work with the latest version since it corrects
defects that are very impacting for us.

The difficulty of this migration is that we can't afford migrations problems
(in order to maintain productivity and work).

That is the reason why I have a couple of questions:

1- Is it possible to have two GIT installations pointing on the same
repositories? 

One of this installation would be GIT 1.7.6.1 used by a restricted number of
people (these people could be called 'beta-testers' of the new GIT version).
The other installation would be GIT 1.7.0.4 used by the other users (the
majority of users) with no impact on their productivity.

Once the beta-tests will be finished and successful, all the users will move
to GIT 1.7.6.1.

2- Do you have any suggestions, trips, hints and best practices in order to
upgrade GIT in such a context?

Thanks a lot for your answers.

Best Regards,

Mikaël Donini.

--
View this message in context: http://git.661346.n2.nabble.com/upgrading-GIT-from-version-1-7-0-4-to-1-7-6-1-tp6808156p6808156.html
Sent from the git mailing list archive at Nabble.com.

Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Sverre Rabbelier]

Heya,

On Mon, Sep 19, 2011 at 14:30, Mikaël <mikael.donini@gmail.com> wrote:
> 1- Is it possible to have two GIT installations pointing on the same
> repositories?

Yes, knowing how deeply Junio cares about backwards compatability,
there will have been no backwards-incompatible changes to the
repository format (none at all actually, IIRC) since 1.7.0 was
released.

> 2- Do you have any suggestions, trips, hints and best practices in order to
> upgrade GIT in such a context?

You should read the following documents that are in git.git:

Documentation/RelNotes/1.7.1.txt
Documentation/RelNotes/1.7.2.txt
Documentation/RelNotes/1.7.3.txt
Documentation/RelNotes/1.7.4.txt
Documentation/RelNotes/1.7.5.txt
Documentation/RelNotes/1.7.6.txt

And make sure that none of the changes mentioned there will affect you
negatively.

-- 
Cheers,

Sverre Rabbelier

Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Andreas Ericsson]

On 09/19/2011 02:30 PM, Mikaël wrote:
> 
> 1- Is it possible to have two GIT installations pointing on the same 
> repositories?
> 

The core structure and layout of a git repository hasn't changed
since may 2005, so it should work just fine provided you use any
git version that actually has a version number.

We've upgraded in a hodge-podge fashion at $dayjob. One of our
servers is still running 1.4.something. We've never even come close
to anything resembling a problem. It's actually a bit weird, since
we started using git in late 2005 and it's so far been the most
reliable and backwards-compatible piece of software we have in the
company pretty much ever since.

> 
> 2- Do you have any suggestions, trips, hints and best practices in
> order to upgrade GIT in such a context?
> 

Since you have such high demands on problem-free migration, I suggest
setting up a repo server running the new git (on the server side) and
having some people test against the new git with both old and new git,
as well as testing new git against the old servers.

Just get a backup first. I'm 99.9999999999999% sure you won't need it
because of anything git does, but better safe than sorry, eh?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Jeff King]

On Mon, Sep 19, 2011 at 02:49:53PM +0200, Andreas Ericsson wrote:

> On 09/19/2011 02:30 PM, Mikaël wrote:
> > 
> > 1- Is it possible to have two GIT installations pointing on the same 
> > repositories?
> > 
> 
> The core structure and layout of a git repository hasn't changed
> since may 2005, so it should work just fine provided you use any
> git version that actually has a version number.
> 
> We've upgraded in a hodge-podge fashion at $dayjob. One of our
> servers is still running 1.4.something. We've never even come close
> to anything resembling a problem. It's actually a bit weird, since
> we started using git in late 2005 and it's so far been the most
> reliable and backwards-compatible piece of software we have in the
> company pretty much ever since.

This is not completely true. Any two versions should be able to
interoperate over the network using the git:// protocol. However, the
disk format has changed slightly over time.

Since v1.6.0 (August 2008), git defaults to using delta base offsets in
packfiles and version 2 of the pack index format. These features are not
understood by versions before v1.5.2 (May 2007) or v1.4.4.5 (July 2008).
A very old git accessing those repositories directly on disk (or by a
dumb protocol like rsync or non-smart http) would have problems[1].

So it has happened[2], but it's important to note that:

  1. We waited a year to flip the default for the code supporting it to
     become more pervasive.

  2. The switch happened on a major version boundary (1.5 -> 1.6),
     was already supported by versions in the prior major series (1.5),
     and we released a maintenance version for the series before that
     (1.4.4.x).

  3. The change, along with the affected versions, was mentioned
     prominently in the 1.6.0 release notes.

So no, I wouldn't expect any disk format issues moving from v1.7.0.4 to
v1.7.6.1. But it never hurts to read the release notes if you're unsure.

-Peff

[1] I do very occasionally run into this while bisecting some ancient
    code on a modern repository.

[2] I suspect a similar thing happened with turning on packed refs
    (around the v1.4.4 era?), but I didn't dig around for details.

Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> [2] I suspect a similar thing happened with turning on packed refs
>     (around the v1.4.4 era?), but I didn't dig around for details.

Also when bisecting down to really ancient versions of git, you may get
complaints from the configuration reader. E.g.

    $ rungit v1.0.0 ls-files
    fatal: bad config file line 78 in .git/config
    $ sed -n 78p .git/config
    [remote "git-gui"]

Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Jeff King]

On Mon, Sep 19, 2011 at 02:26:55PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > [2] I suspect a similar thing happened with turning on packed refs
> >     (around the v1.4.4 era?), but I didn't dig around for details.
> 
> Also when bisecting down to really ancient versions of git, you may get
> complaints from the configuration reader. E.g.
> 
>     $ rungit v1.0.0 ls-files
>     fatal: bad config file line 78 in .git/config
>     $ sed -n 78p .git/config
>     [remote "git-gui"]

Ugh, yeah. There are similar problems with some specific config options
(one I run into a lot these days is that "pager.foo" used to complain if
the value was non-boolean, but now you can put in an arbitrary command).
But those only bite you if you start using the new config options (which
you obviously are not doing until after you upgrade).

But your example will bite anyone because git generates remote config
like that by default.

Anyway, most of that is only applicable if you are crossing several
major version boundaries, or are using ancient versions of git. I'm
pretty sure that v1.7.0.x -> v1.7.6.x is pretty safe.

-Peff

Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.

[Jakub Narebski]

Mikaël <mikael.donini@gmail.com> writes:

> Today, it is the time for us to upgrade from version 1.7.0.4 to
> 1.7.6.1 (the latest stable).  It is important for us to work with
> the latest version since it corrects defects that are very impacting
> for us.
> 
> The difficulty of this migration is that we can't afford migrations problems
> (in order to maintain productivity and work).
> 
> That is the reason why I have a couple of questions:
> 
> 1- Is it possible to have two GIT installations pointing on the same
> repositories? 
> 
> One of this installation would be GIT 1.7.6.1 used by a restricted number of
> people (these people could be called 'beta-testers' of the new GIT version).
> The other installation would be GIT 1.7.0.4 used by the other users (the
> majority of users) with no impact on their productivity.
> 
> Once the beta-tests will be finished and successful, all the users will move
> to GIT 1.7.6.1.

Git is forward and backward compatibile, meaning that old clients can
connect to new servers (perhaps not using new features), and new
clients can connect to old servers.

The exceptions are few (submodules, packed refs), are always announced
long in advance, with a long transition period: first a configuration
variable is added to switch to new incompatibile behavior defaulting
to old behavior, only after a time there is switch to new improved
incompatibile version.

-- 
Jakub Narębski