On 1/15/14, 12:44 PM, Kyle Sluder wrote:
> Is there foreseeable benefit to moving them into the FS layer?
I can't think of any benefit other than a design that seems cleaner. I'm sure
Branko can though.
> To be completely explicit, the problem as I understand it is that since
> touching a file i
On Wed, Jan 15, 2014, at 11:27 AM, Ben Reser wrote:
> On 1/15/14, 10:34 AM, Branko Čibej wrote:
> > We certainly have to hack thinks to map non-recursive directory locks to any
> > reasonable locking model in Subversion. This is because of Subversion's
> > bubble-up storage model, in which the revi
On 1/15/14, 10:34 AM, Branko Čibej wrote:
> We certainly have to hack thinks to map non-recursive directory locks to any
> reasonable locking model in Subversion. This is because of Subversion's
> bubble-up storage model, in which the revisions of all parent directories of a
> change are updated by
On 15.01.2014 19:28, Ben Reser wrote:
> On 1/15/14, 10:22 AM, Kyle Sluder wrote:
>> To be clear, this isn't implying that `svn lock` of a directory will work
>> over DAV, correct? Just that the repository supports storing the fact that
>> some other DAV client has LOCKed a directory, and the DAV
Here is at least one old thread on this topic:
http://svn.haxx.se/dev/archive-2004-10/1228.shtml
Sadly, I have no recollection of ever participating in this discussion, but
there I am :)
Mark
On 1/15/14, 10:22 AM, Kyle Sluder wrote:
> To be clear, this isn't implying that `svn lock` of a directory will work
> over DAV, correct? Just that the repository supports storing the fact that
> some other DAV client has LOCKed a directory, and the DAV protocol layer
> supports communicating th
On Wed, Jan 15, 2014 at 1:16 PM, Ben Reser wrote:
> On 1/15/14, 9:52 AM, Branko Čibej wrote:
> > There's probably a good reason why we didn't implement directory locks
> > when the locking feature was developed. In any case it's not a trivial
> > feature.
>
> I don't recall what the reason was at
> On Jan 15, 2014, at 9:39 AM, Ben Reser wrote:
>
>> On 1/13/14, 7:02 PM, Kyle Sluder wrote:
>> I understand that implementing this would require all commits to search
>> for lock properties on every ancestor of every changed file or
>> directory. It essentially amounts to an extension of inherit
On 1/15/14, 9:52 AM, Branko Čibej wrote:
> There's probably a good reason why we didn't implement directory locks
> when the locking feature was developed. In any case it's not a trivial
> feature.
I don't recall what the reason was at the time, but I'd bet it was just a pain
to deal with the inhe
On 15.01.2014 18:39, Ben Reser wrote:
> On 1/13/14, 7:02 PM, Kyle Sluder wrote:
>> I understand that implementing this would require all commits to search
>> for lock properties on every ancestor of every changed file or
>> directory. It essentially amounts to an extension of inheritable
>> propert
On 1/13/14, 7:02 PM, Kyle Sluder wrote:
> I understand that implementing this would require all commits to search
> for lock properties on every ancestor of every changed file or
> directory. It essentially amounts to an extension of inheritable
> properties to the RA layer. Which would be pretty n
I had a quick discussion on the IRC channel today about locking entire
directories in my repository. [1]
My company recently submitted version 4.0 of our application to Apple's
App Store. That submission was created from a tag which was itself
created from the 4.0 branch.
While we're waiting for
12 matches
Mail list logo
