On Wed, Jan 15, 2014 at 10:19 PM, Ben Reser wrote:
> On 1/15/14, 1:05 PM, Mojca Miklavec wrote:
>> I was wondering whether "-r REV SRC" and "SRC@REV" in "svn copy" are
>> supposed to behave differently or not.
>
> Yes they have different behavior. You probably want to read about Peg and
> Operativ
On 1/15/14, 1:05 PM, Mojca Miklavec wrote:
> I was wondering whether "-r REV SRC" and "SRC@REV" in "svn copy" are
> supposed to behave differently or not.
Yes they have different behavior. You probably want to read about Peg and
Operative Revisions here:
http://svnbook.red-bean.com/en/1.7/svn.adv
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
Hi,
I was wondering whether "-r REV SRC" and "SRC@REV" in "svn copy" are
supposed to behave differently or not.
I was trying to recover a file that has already been deleted from the
repository, but using "-r" syntax failed to work while @REV completed
successfully:
> svn copy -r 10 ^/trunk/path/
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 09.01.2014 20:19, Branko Čibej wrote:
> On 09.01.2014 17:09, Mojca Miklavec wrote:
>> I'm unable to reproduce the faulty behaviour if I do a checkout from
>> the same network where the server is located, no matter what I try
>> (upgrading SVN client doesn't "help" triggering the error). Philip
>
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 replied yesterday, but my post seems to have disappeared.
I figured it out, and the key was your reproduction and my realisation I
wasn't seeing a FIN from my server. It turns out that in every case the last
392598 71.906863000 10.222.3.88 10.14.11.50 HTTP 1434 Continuation or
non-HTTP traffic
16 matches
Mail list logo
