Re: svn commit: r1527211 - /subversion/trunk/subversion/svnserve/svnserve.c

2013-09-29 Thread Stefan Sperling
On Sun, Sep 29, 2013 at 07:08:25AM +0200, Branko Čibej wrote: > The typedef is in an "#if APR_HAS_THREADS" block, the use in line 529 is > not. Apparently the APR is not compiled with thread support. Yes,and deliberately so. Because evidently nobody else does.

Re: svn commit: r1527211 - /subversion/trunk/subversion/svnserve/svnserve.c

2013-09-29 Thread Stefan Sperling
On Sun, Sep 29, 2013 at 10:26:07AM +0200, Stefan Sperling wrote: > On Sun, Sep 29, 2013 at 07:08:25AM +0200, Branko Čibej wrote: > > The typedef is in an "#if APR_HAS_THREADS" block, the use in line 529 is > > not. Apparently the APR is not compiled with thread support. > > Yes,and deliberately so

Found a bug with relative file:// urls

2013-09-29 Thread Sjon Hortensius
Hi, pretty sure this is unwanted behaviour: # svn ls file://./ svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 2304: assertion failed (svn_uri_is_canonical(url, pool)) Aborted (core dumped) The path contains a repository and the absolute path works fine. Any relative path seems

Re: Found a bug with relative file:// urls

2013-09-29 Thread Branko Čibej
On 29.09.2013 14:24, Sjon Hortensius wrote: > Hi, > > pretty sure this is unwanted behaviour: > > # svn ls file://./ > svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 2304: > assertion failed (svn_uri_is_canonical(url, pool)) > Aborted (core dumped) > > The path contains a reposito

Re: Respecting inherited Windows file permissions on file create

2013-09-29 Thread Jason Kresowaty
> From: Branko ÄŒibej > Date: Sun, 29 Sep 2013 07:14:07 +0200 > This is not in fact a bug in Subversion > The solution that jiggles the security descriptor is not acceptable. I note that svn is not touching the place where the inherit is actually assigned (a directory), yet it is interfering w

Re: Respecting inherited Windows file permissions on file create

2013-09-29 Thread Branko Čibej
On 29.09.2013 16:06, Jason Kresowaty wrote: > The solution Ivan mentioned of creating a temp file in the same > directory as the final file is common. I agree this is something we can look at. There were good reasons to not create temporary files in the target directories, but we can certainly rev

Re: Moves in FSFS

2013-09-29 Thread Stefan Fuhrmann
On Sun, Sep 29, 2013 at 2:08 AM, Bill Tutt wrote: > On a slightly different note I noticed this oddity in lib_fs_fs/dag.c from > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/dag.c?annotate=1517479 > > 703 > jpieper849539

Re: Moves in FSFS

2013-09-29 Thread Stefan Fuhrmann
On Sat, Sep 28, 2013 at 12:36 PM, Branko Čibej wrote: > On 28.09.2013 12:06, Bill Tutt wrote: > > Move tracking can clearly make ones head spin. :) > > Brane: Could Julian and Stephan be asking about how to map between > arbitrary revisions thinking of tree merge scenarios? > > > There are two,

RE: Moves in FSFS

2013-09-29 Thread Bert Huijben
Hi Stefan, Are you sure there are no behavior changes by changing this? If you copy nodes at every level the resulting nodes are the same as when you only copy a root. (We had a lot of this in the wc-1.0 code). Tweaking between copyfrom_* and copyroot_* is quite easy to get

Re: Moves in FSFS

2013-09-29 Thread Stefan Fuhrmann
On Sun, Sep 29, 2013 at 8:46 PM, Bert Huijben wrote: > Hi Stefan, > > ** ** > > Are you sure there are no behavior changes by changing this? > Reasonably sure. Previously, it read noderev->copyfrom_path = copy_something(); noderev->copyfrom_path = NULL; /* result of cop

Re: Moves in FSFS

2013-09-29 Thread Branko Čibej
On 29.09.2013 20:59, Stefan Fuhrmann wrote: > > On Sun, Sep 29, 2013 at 8:46 PM, Bert Huijben > wrote: > > Hi Stefan, > > > > Are you sure there are no behavior changes by changing this? > > > Reasonably sure. Previously, it read > > noderev->

Re: Moves in FSFS

2013-09-29 Thread Branko Čibej
On 29.09.2013 19:34, Stefan Fuhrmann wrote: > > On Sat, Sep 28, 2013 at 12:36 PM, Branko Čibej > wrote: > > > Exactly. And this is the second issue of the two I mentioned: in > order to make merge aware of moves, as opposed to copies, you have > to be able to

Re: Respecting inherited Windows file permissions on file create

2013-09-29 Thread Ivan Zhakov
On 29 September 2013 18:49, Branko Čibej wrote: > On 29.09.2013 16:06, Jason Kresowaty wrote: > > The solution Ivan mentioned of creating a temp file in the same directory as > the final file is common. > > > I agree this is something we can look at. There were good reasons to not > create tempora

Re: Respecting inherited Windows file permissions on file create

2013-09-29 Thread Ben Reser
On 9/29/13 2:15 PM, Ivan Zhakov wrote: > Brane, do you remember reasons for creating temporary files in > .svn/tmp instead of target directory? Is it pre-wcng decision? I haven't looked at how WCNG processes things in this respect but the old WC code would create temp files and then a log of thing

Re: Respecting inherited Windows file permissions on file create

2013-09-29 Thread Branko Čibej
On 29.09.2013 23:15, Ivan Zhakov wrote: > On 29 September 2013 18:49, Branko Čibej wrote: >> On 29.09.2013 16:06, Jason Kresowaty wrote: >> >> The solution Ivan mentioned of creating a temp file in the same directory as >> the final file is common. >> >> >> I agree this is something we can look at