On Wed, 2014-08-13 at 09:20 -0700, Ronnie Sahlberg wrote:
> David,
>
> One possible solution can be to use the external database daemon I am
> working of for ref transactions.
> Since this makes all refs be stored in a dedicated database instead of
> the filesystem you no longer are dependent on f
David,
One possible solution can be to use the external database daemon I am
working of for ref transactions.
Since this makes all refs be stored in a dedicated database instead of
the filesystem you no longer are dependent on file system semantics.
While not in the official git trees yet I would
On Wed, Jun 18, 2014 at 4:33 AM, Michael Haggerty wrote:
> On 06/13/2014 11:25 PM, Junio C Hamano wrote:
>> Ronnie Sahlberg writes:
>>
>>> It gets even more hairy :
>>> If the server has A/a and a/b and you clone it it becomes A/a and A/b
>>> locally. Then you push back to the server and you end
On 06/13/2014 11:25 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> It gets even more hairy :
>> If the server has A/a and a/b and you clone it it becomes A/a and A/b
>> locally. Then you push back to the server and you end up with three
>> refs on the server: A/a A/b and a/b.
>
> That
On Fri, 2014-06-13 at 12:05 -0700, Ronnie Sahlberg wrote:
> Thinking about it more.
>
> I think we want to wait until the ref transaction API work is
> finished. The ref transactions API is in progress and it aims to add
> transactions for ref updates as a first step but then it aims to
> define a
On Fri, Jun 13, 2014 at 2:11 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> ... The first
>> backend will be the current files based structure but I also will add
>> an optional backend using a TDB database.
>
> I am assuming that as part of the transactions work, accesses to
> reflogs
Ronnie Sahlberg writes:
> It gets even more hairy :
> If the server has A/a and a/b and you clone it it becomes A/a and A/b
> locally. Then you push back to the server and you end up with three
> refs on the server: A/a A/b and a/b.
That is part of the transition in deployment. David who wants
Ronnie Sahlberg writes:
> ... The first
> backend will be the current files based structure but I also will add
> an optional backend using a TDB database.
I am assuming that as part of the transactions work, accesses to
reflogs will also have their own backends?
> You could then very easily cr
Thinking about it more.
I think we want to wait until the ref transaction API work is
finished. The ref transactions API is in progress and it aims to add
transactions for ref updates as a first step but then it aims to
define a public API for all public ref functions. As part of that I
will also
On Thu, Jun 12, 2014 at 12:47 PM, Junio C Hamano wrote:
> David Turner writes:
>
>> This issue bit us again recently.
>>
>> In talking with some colleagues, I realized that the previous version
>> of this patch, in addition to being potentially slow, was incomplete.
>> Specifically, it didn't han
Torsten Bögershausen writes:
> Or try to have a functionality to always use packed refs, and have a
> configuration
> for it:
>
> The advantage can be that branch names like "Branch" and "BRANCH" can live
> together
> in a project, regardless if you have a case sensitive or insensitve file
> s
David Turner writes:
> On Thu, 2014-06-12 at 12:47 -0700, Junio C Hamano wrote:
>> David Turner writes:
>>
>> > This issue bit us again recently.
>> >
>> > In talking with some colleagues, I realized that the previous version
>> > of this patch, in addition to being potentially slow, was incomp
On 2014-06-13 01.30, David Turner wrote:
> On Thu, 2014-06-12 at 12:47 -0700, Junio C Hamano wrote:
>> David Turner writes:
>>
>>> This issue bit us again recently.
>>>
>>> In talking with some colleagues, I realized that the previous version
>>> of this patch, in addition to being potentially slo
On Thu, 2014-06-12 at 12:47 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > This issue bit us again recently.
> >
> > In talking with some colleagues, I realized that the previous version
> > of this patch, in addition to being potentially slow, was incomplete.
> > Specifically, it didn
David Turner writes:
> This issue bit us again recently.
>
> In talking with some colleagues, I realized that the previous version
> of this patch, in addition to being potentially slow, was incomplete.
> Specifically, it didn't handle the case of refs/heads/case/one vs
> refs/heads/CASE/two; the
This issue bit us again recently.
In talking with some colleagues, I realized that the previous version
of this patch, in addition to being potentially slow, was incomplete.
Specifically, it didn't handle the case of refs/heads/case/one vs
refs/heads/CASE/two; these are case clones even though the
16 matches
Mail list logo
