Johannes Schindelin [off-list ref] writes:
quoted
There must be at least some deprecation period during which
also the old .lock lockfiles are considered and created.
Just imagine someone modifying the ref with an older version,
which knows nothing about ..lck.
As lock files are only supposed to be created by Git itself, and have a
maximum lifetime until the end of the process, I think we do not need a
grace period at all.
Could there be people with slightly older git and shiny new jgit (or the
other combination) working on the same repository?
Hi,
On Fri, 8 May 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
There must be at least some deprecation period during which also the
old .lock lockfiles are considered and created. Just imagine someone
modifying the ref with an older version, which knows nothing about
..lck.
As lock files are only supposed to be created by Git itself, and have
a maximum lifetime until the end of the process, I think we do not
need a grace period at all.
Could there be people with slightly older git and shiny new jgit (or the
other combination) working on the same repository?
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.
Ciao,
Dscho
2009/5/8 Johannes Schindelin [off-list ref]:
On Fri, 8 May 2009, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
There must be at least some deprecation period during which also the
old .lock lockfiles are considered and created. Just imagine someone
modifying the ref with an older version, which knows nothing about
..lck.
As lock files are only supposed to be created by Git itself, and have
a maximum lifetime until the end of the process, I think we do not
need a grace period at all.
Could there be people with slightly older git and shiny new jgit (or the
other combination) working on the same repository?
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.
I certainly hope that'll be you, one day.
Of course people run git concurrently on the same repo. Even from different
machines.
That's _why_ we have the locking in the first place.
And of course there will be different versions of git installed on
these machines.
And most certainly the people will not know what they were doing, blame the
hole on Git (and maybe even shoot you in return, after they'll find that stupid
message of yours in archives).
Alex Riesen [off-list ref] wrote:
2009/5/8 Johannes Schindelin [off-list ref]:
quoted
On Fri, 8 May 2009, Junio C Hamano wrote:
quoted
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.
quoted
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.