On Sat, Jan 5, 2013 at 11:12 AM, Jeff King 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" name.
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.
Martin Fick 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 effort and the resul
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
> 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 availa
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 Mar
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 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
Jeff King 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 would t
Jeff King 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 tra
Jeff King wrote:
>On Fri, Dec 28, 2012 at 09:15:52AM -0800, Junio C Hamano wrote:
>
>> Martin Fick 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
On Fri, Dec 28, 2012 at 09:15:52AM -0800, Junio C Hamano wrote:
> Martin Fick 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 rep
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 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 Friday, December 28, 2012 09:58:36 am Junio C Hamano
wrote:
> Martin Fick 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 th
Martin Fick 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 something that git wan
Martin Fick 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 ensure that the
On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote:
> 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
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
19 matches
Mail list logo
