Alex Riesen <raa.lkml@xxxxxxxxx> wrote:
> 2009/5/8 Johannes Schindelin <Johannes.Schindelin@xxxxxx>:
> > On Fri, 8 May 2009, Junio C Hamano wrote:
> >>
> >> Could there be people with slightly older git and shiny new jgit (or the
> >> other combination) working on the same repository?
Yes, Gerrit Code Review runs a JGit daemon 24/7. I have a lot
of folks running Gerrit servers inside their company networks,
and two running them on the public internet. Gerrit runs bleeding
edge JGit, and would most certainly pick up a "..lck" patch there
before they upgrade their git-core package.
This is one of those cases where the locking is really important,
because you should be able to concurrently access the same git
repository from the command line with git-core utilities while
Gerrit's daemon process is servicing network based user requests.
> > You mean concurrently? ??Sure, but do we have to care? ??People doing this
> > certainly know what they are doing, and live happily even with a 0.5"
> > hole in their foot.
Yes, dammit, we should care.
> Of course people run git concurrently on the same repo. Even from different
> machines.
Even ignoring JGit and Gerrit's daemon process entirely as "useless
stupid projects that never should have happened", _this_ is enough
of a reason to care. People use Git on NFS all of the time.
With different machines. Accessing the same repo. Those different
machines most likely have different versions of Git installed.
> That's _why_ we have the locking in the first place.
Yes.
I've actually thought about this "fix.vm.lock" being invalid for
quite a while now, and wanted to change lockfile.c to use another
pattern that was already an invalid ref name, like Junio's "..lck"
proposal does. But I've never been able to come up with a sane way
to deal with the transition. So I never brought the topic up before.
I still don't have a sane way to deal with the transition.
The only thing I can think of is:
- grab ".lock"
- grab "..lck"
- do stuff
- commit by link("..lck", orig)
- ulink ".lock"
And maybe in a year we stop writing ".lock".
But, here's news for you, *#@!#@@!$@!*&@! distributions are still
shipping 1.5.0-1.5.0.3. In particular I've spent the better part
of this past two weeks telling new Git users to upgrade off of these
versions due to the pread() bug introduced in [1] and fixed in [2].
I've seen WAAAAY too many "fatal: cannot pread pack file:" errors.
Enough for a lifetime.
[1] http://repo.or.cz/w/git.git?a=commit;h=6d2fa7f1b489c65e677c18eda5c144dbc5d614ab
[2] http://repo.or.cz/w/git.git?a=commit;h=a91d49cd369ac5fc8e1a17357a975d09cf6c8cb3
--
Shawn.
--
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