On Sat, Jan 5, 2013 at 11:12 AM, Jeff King p...@peff.net wrote:
On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote:
The general approach is to setup a transaction and either
commit or abort it. A transaction can be setup by renaming
an appropriately setup directory to the ref.lock
On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote:
The general approach is to setup a transaction and either
commit or abort it. A transaction can be setup by renaming
an appropriately setup directory to the ref.lock name. If
the rename succeeds, the transaction is begun. Any
From: Martin Fick
Sent: Thursday, January 03, 2013 6:53 PM
Any thoughts on this idea? Is it flawed? I am trying to
write it up in a more formal generalized manner and was
hoping to get at least one it seems sane before I do.
If you are assuming that atomic renames, etc. are available,
On Friday, January 04, 2013 10:52:43 am Pyeron, Jason J
CTR (US) wrote:
From: Martin Fick
Sent: Thursday, January 03, 2013 6:53 PM
Any thoughts on this idea? Is it flawed? I am
trying
to write it up in a more formal generalized manner
and
was hoping to get at least one it seems
Martin Fick mf...@codeaurora.org writes:
Any thoughts on this idea? Is it flawed? I am trying to
write it up in a more formal generalized manner and was
hoping to get at least one it seems sane before I do.
The general impression I have been getting was that this isn't even
worth the
Any thoughts on this idea? Is it flawed? I am trying to
write it up in a more formal generalized manner and was
hoping to get at least one it seems sane before I do.
Thanks,
-Martin
On Monday, December 31, 2012 03:30:53 am Martin Fick wrote:
On Thursday, December 27, 2012 04:11:51 pm
On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote:
It concerns me that git uses any locking at all, even for
refs since it has the potential to leave around stale
locks.
...
[a previous not so great attempt to fix this]
...
I may have finally figured out a working loose ref
On Saturday, December 29, 2012 03:18:49 pm Martin Fick wrote:
Jeff King p...@peff.net wrote:
On Thu, Dec 27, 2012 at 04:11:51PM -0700, Martin Fick
wrote:
My idea is based on using filenames to store sha1s
instead of file contents. To do this, the sha1 one of
a ref would be stored in a
On Thu, Dec 27, 2012 at 04:11:51PM -0700, Martin Fick wrote:
For a single user repo this is not a big deal, the lock can
always be cleaned up manually (and it is a rare occurrence).
However, in a multi user server environment, possibly even
from multiple hosts over a shared filesystem
On Fri, Dec 28, 2012 at 07:50:14AM -0700, Martin Fick wrote:
Hmm, actually I believe that with a small modification to the
semantics described here it would be possible to make multi
repo/branch commits work. Simply allow the ref filename to
be locked by a transaction by appending the
On Fri, Dec 28, 2012 at 09:15:52AM -0800, Junio C Hamano wrote:
Martin Fick mf...@codeaurora.org writes:
Hmm, actually I believe that with a small modification to the
semantics described here it would be possible to make multi
repo/branch commits work
Shawn talked about adding
Jeff King p...@peff.net wrote:
On Fri, Dec 28, 2012 at 09:15:52AM -0800, Junio C Hamano wrote:
Martin Fick mf...@codeaurora.org writes:
Hmm, actually I believe that with a small modification to the
semantics described here it would be possible to make multi
repo/branch commits
Jeff King p...@peff.net wrote:
On Fri, Dec 28, 2012 at 07:50:14AM -0700, Martin Fick wrote:
Hmm, actually I believe that with a small modification to the
semantics described here it would be possible to make multi
repo/branch commits work. Simply allow the ref filename to
be locked by a
Jeff King p...@peff.net wrote:
On Thu, Dec 27, 2012 at 04:11:51PM -0700, Martin Fick wrote:
My idea is based on using filenames to store sha1s instead of
file contents. To do this, the sha1 one of a ref would be
stored in a file in a directory named after the loose ref. I
believe this
Martin Fick mf...@codeaurora.org writes:
3) To create a ref, it must be renamed from the null file (sha
...) to the new value just as if it were being updated
from any other value, but there is one extra condition:
before renaming the null file, a full directory scan must be
done to
Martin Fick mf...@codeaurora.org writes:
Hmm, actually I believe that with a small modification to the
semantics described here it would be possible to make multi
repo/branch commits work
Shawn talked about adding multi repo/branch transaction
semantics to jgit, this might be
On Friday, December 28, 2012 09:58:36 am Junio C Hamano
wrote:
Martin Fick mf...@codeaurora.org writes:
3) To create a ref, it must be renamed from the null
file (sha ...) to the new value just as if it were
being updated from any other value, but there is one
extra condition: before
On Wednesday, December 26, 2012 01:24:39 am Michael Haggerty
wrote:
... lots of discussion about ref locking...
It concerns me that git uses any locking at all, even for
refs since it has the potential to leave around stale locks.
For a single user repo this is not a big deal, the lock can
18 matches
Mail list logo
