Re: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

[Daniel Näslund]

On Fri, Jun 25, 2010 at 02:03:17AM +, Paul Smedley wrote:
> [[[
> Fix paths & command prompts for OS/2 by re-using WIN32 #ifdef's
> 
> * subversion/libsvn_subr/dirent_uri.c
> * subversion/libsvn_subr/io.c
> * subversion/libsvn_subr/prompt.c
> * subversion/libsvn_ra_local/split_url.c
> * subversion/libsvn_fs_fs/fs_fs.c
>   (various): Use WIN32 code for paths with drive letters and command 
> prompts
> ]]]

I (and probably other people too) have a hard time reading your patch
[1]. :)

Why does it look like it's base64 encoded?

Cheers,
Daniel

[1] http://svn.haxx.se/dev/archive-2010-06/0394.shtml

Re: [Patch] - Fix paths on OS/2 - patch for trunk - svn-paths-trunk.diff [1/1]

[Paul Smedley]

Hi All,

This patch is for trunk:

[[[
Fix paths & command prompts for OS/2 by re-using WIN32 #ifdef's

* subversion/libsvn_subr/dirent_uri.c
* subversion/libsvn_subr/io.c
* subversion/libsvn_subr/prompt.c
* subversion/libsvn_ra_local/split_url.c
* subversion/libsvn_fs_fs/fs_fs.c
  (various): Use WIN32 code for paths with drive letters and command 
prompts
]]]




-- 
Cheers,

Paul.

begin 666 svn-paths-trunk.diff
m26y...@z('-U8G9EPT*+2-I9B!D969I;F5D*%=)3C,R*2!\?"!D969I;F5D
M*%]?0UE'5TE.7U\I#0HK(VEF(&1E9FEN960H5TE.,S(I('Q\(&1E9FEN960H
m7u]#64=724y?...@?'p...@9&5F:6YE9"A?7T]3,E]?*0T*("`@:6...@*&QE;B`^
M/2`R("8F(&1I6=W:6X@;W(@3U,O,B`J+PT*("`@("`@("`...@*0t*
M("`@("`M+6QE;CL-"B`-"D!`("TR-S6=W:6X@;W(@3U,O,B`J+PT*(`T*("`@6=W:6...@*b\-"B`@("`@("`@('T-"BTC:6...@9&5F:6YE9"A724XS,b...@?'P@
M9&5F:6YE9"A?7T-91U=)3E]?*0T**R-I9B!D969I;F5D*%=)3C,R*2!\?"!D
M969I;F5D*%]?0UE'5TE.7U\I('Q\(&1E9FEN960H7U]/4S)?7RD-"B`@("`@
M("`O*B!/;B!7:6YD;W=S('1H92!F:7)S="!S96=M96YT(&-A;B!B92!A(&1R
M:79E(&QE='1E7!E(#T]('1Y<&5?
M9&ER96YT("8F#0I`0"`M-#8U+#<@*S0V-2PW($!`#0H@("`@("`@("![#0H@
M("`@("`@("`@("\J($YO;W`@'0[#0H@("`@("`@("`@(&-A
M;F]N7W-E9VUE;G1S*RL[#0H@("`@("`@("!]#0HM(V5N9&EF("\J(%=)3C,R
M(&]R($-Y9W=I;B`J+PT**R-E;F1I9B`O*B!724XS,B!O6=W:6X@;W(@
M3U,O,B`J+PT*("`@("`@(&5LPT*("`@("`@("`@
M("`O*B!8.B]F;v...@86yd(%...@z+v)A7!E(#T]('1Y<&5?9&ER96YT*2`F)B!P871H,5MI("T@
M,5T@/3T@)SHG*0T*+2-E;F1I9B`O*B!724XS,B!O6=W:6...@*b\-"BLC
M96YD:6...@+rh@5TE.,S(@;W(@0WEG=VEN(&]R($]3+S(@*B\-"B`@("`@("`@
M("`@("D-"B`@("`@("`@('L-"B`@("`@("`@("`@:6...@*'!A=&@R6VE=(#T]
M("7!E7V1I6=W:6...@*b\-"BLC96YD:68@
m...@5te.,S(@;W(@0WEG=VEN(&]R($]3+S(@*B\-"B`@("`@("!\?"`H<&%T
M:#);<&%T:#%?;&5N72`]/2`G+R<@?'P@<&%T:#);<&%T:#%?;&5N72`]/2`G
M7#`G*3L-"B`-"B`@(')E='5R;B!&04Q313L-"D!`("TY,3,L-R`K.3$S+#<@
M0$`-"B!S=FY?8F]O;&5A;E]T#0H@PT*+2-I9B!D969I
M;F5D*%=)3C,R*2!\?"!D969I;F5D*%]?0UE'5TE.7U\I#0HK(VEF(&1E9FEN
M960H5TE.,S(I('Q\(&1e9fen960h7u]#64=724y?...@?'p...@9&5F:6YE9"A?
M7T]3,E]?*0T*("`...@+rh@3...@5ven9&]W6=W:6...@*b\-"BLC96YD:6...@+rh@5TE.
M,S(@;W(@0WEG=VEN(&]R($]3+S(@*B\-"B`@("`@("`@("D-"B`@("`@("`@
M("`...@861d7w-e<&%R871O6=W:6X@;W(@3U,O
M,B`J+PT*("`@("`@("`@("`@("`...@*0t*("`@("`@("`@("`@("!A9&1?2!L971T97(N("HO#0HM(VEF(&1E9FEN960H
M5TE.,S(I('Q\(&1E9FEN960H7U]#64=724Y?7RD-"BLC:6...@9&5F:6YE9"A7
M24XS,b...@?'p...@9&5F:6YE9"A?7T-91U=)3E]?*2!\?"!D969I;F5D*%]?3U,R
M7U\I#0H@("!I9B`H*"AD:7)E;G1;,%T@/CT@)T$G("8F(&1IPT*("`...@8v]nPT*
m...@+rh@(R,C($]N(%=I;F1O=W,L(&%P7,@2!T:&4...@8w5r"!C86QL#0HK("`O*B!/;B!7:6YD;W=S("8...@3u,O,BP@:G5S="!S970@
M=&AE(&9I;&4...@871t"!C86QL(&]U&ET("TM(&]N('5N:7@@8V%L;"!O=7(@:6YT97)n...@9g5n8w1i;VX-"B`@
M('=H:6-H(&%T=&5M<'1S('1O(&AO;F]R('1H92!U;6%S:r...@*b\-"BTC:69N
M9&5F(%=)3C,R#0HK(VEF("@A9&5F:6YE9"A724XS,BD@)B8@(61E9FEN960H
M7U]/4S)?7RDI#0H@("!R971U&5C=71A8FQE+`T*("`@("`@("`@("`@
M("`@("`@("`@("`@("`@(&EG;F]R95]E;F]E;G0L('!O;VPI.PT*("-E;'-E
M#0I`0"`M,34U-2PW("LQ-34U+#<@0$`-"B`@("`@("`@("`@("`@("`@("`@
M("`@("`@(&-O;G-T(&-H87(@*G!A=&@L#0H@("`@("`@("`@("`@("`@("`@
M("`@("`@("!A<')?<&]O;%]T("IP;V]L*0T*('L-"BTC:6...@9&5F:6YE9"A!
M4%)?2$%37U5315(I("8F("%D969I;F5D*%=)3C,R*0T**R-I9B!D969I;F5D
M*$%04E](05-?55-%4BD@)B8@(61E9FEN960H5TE.,S(I("8F(61E9FEN960H
M7U]/4S)?7RD-"B`@(&%P2!.5$93(')E<&]R=',@14%#
M0T534R!A;F0-"B`@("`@($9!5"]&050S,B!R97!O2X-"D!`("TS-S8Y+#,@*S,W-CDL-"!`0`T*(`T*("`@
M#H@7!I8V%L;'D@:&%V92!T;R!S:VEP('1H92!L96%D:6YG("\@:6...@=&AE#0H@
M("`@("!P871H('-T87)TPT*
m+2-i9fyd...@5te.,S(-"BL-"BLC:6...@*"%D969I;F5D(%=)3C,R("8F("%D
M969I;F5D(%]?3U,R7U\I#0H@("!A<')?

Re: [Patch] OS/2 configuration changes - svn-config.diff [1/1]

[Paul Smedley]

Hi All,

This one should be suitable for both the 1.6.x branch & the trunk.

On Fri, 25 Jun 2010 03:28:10 UTC, "Paul Smedley" 
 wrote:

> Hi All,
> 
> Patches to change configuration slightly for OS/2 clients.
> 
> [[[
>Fix Subversion on OS/2
> 
>* subversion/libsvn_subr/config_file.c
>  (svn_config_ensure): Add OS/2 .cmd files as type eol_native
>* subversion/include/svn_config.h
>(SVN_CONFIG__DEFAULT_GLOBAL_IGNORES_LINE_2): Add additional OS2 
> file types to ignore list
> ]]]
> 


-- 
Cheers,

Paul.

Re: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

[Paul Smedley]

Hi All - jsut to eb clear - this patch is for the 1.6.x branch - 
another will follow shortly for trunk.

On Fri, 25 Jun 2010 02:03:17 UTC, "Paul Smedley" 
 wrote:

> [[[
> Fix paths & command prompts for OS/2 by re-using WIN32 #ifdef's
> 
> * subversion/libsvn_subr/dirent_uri.c
> * subversion/libsvn_subr/io.c
> * subversion/libsvn_subr/prompt.c
> * subversion/libsvn_ra_local/split_url.c
> * subversion/libsvn_fs_fs/fs_fs.c
>   (various): Use WIN32 code for paths with drive letters and command 
> prompts
> ]]]
> 
> 


-- 
Cheers,

Paul.

[Patch] OS/2 configuration changes - svn-config.diff [1/1]

[Paul Smedley]

Hi All,

Patches to change configuration slightly for OS/2 clients.

[[[
   Fix Subversion on OS/2

   * subversion/libsvn_subr/config_file.c
 (svn_config_ensure): Add OS/2 .cmd files as type eol_native
   * subversion/include/svn_config.h
   (SVN_CONFIG__DEFAULT_GLOBAL_IGNORES_LINE_2): Add additional OS2 
file types to ignore list
]]]

-- 
Cheers,

Paul.


begin 666 svn-config.diff
m26y...@z('-U8G9E&5C=71A8FQE(B`@("`@("`@("`@("`@
M("`@("`@("`...@3dp-"B`@("`@("`@("(C("HN='AT(#T@7=O7!E/6EM86=E+VIP96'1E;f...@=&AE
M(&QI

Re: Ruby bindings don't work with 1.9 + patch

[Joe Swatosh]

On Thu, Jun 24, 2010 at 4:15 AM, Hyrum K. Wright
 wrote:
> Applied in r957507.  I noticed the patch was against 1.6.12, but it
> applied cleanly to trunk.  In the future, please make patches against
> trunk (and hopefully include a log message).
>
> Should this be backported to the 1.6.x branch?
>
> Cheers,
> -Hyrum
>

Thanks Joe and Hyrum,

I'm working on getting the bindings to build 1.8.7 on mingw, so I'm
completely distracted and barely keeping up with the list

--
Joe Swatosh

Re: Stalish downloads still on Tigris

[C. Michael Pilato]

Jack Repenning wrote:
> It turns out that there are still quite a few folks downloading the rather 
> stale-ish binary packages still stored on Tigris (Subversion installers and 
> language bindings). We see around 40,000 downloads of these files per week, 
> even though the newest is version 1.6.6. This is probably mostly confusion. I 
> wonder if we shouldn't do something to un-confuse all these people?
> 
> What I'd propose would be:
> 1. move these packages to some other directory, that a bit more clearly shows 
> their status (such as the existing "Windows Archive" one)
> 2. Put something (banner note, or URL-reference, something like that) into 
> the folder to direct lost wanderers to packages.html or similar.

I've done a *bunch* of folder renaming and file relocating in the
subversion.tigris.org Docs-n-Files area.  I think you'll find the situation
improved.  All the folders containing non-latest stuff are tagged with
"archived", and there are pointers in the descriptions of the top-most
Source Code and Windows Binaries to the packages.html page at Apache.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

[Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

[Paul Smedley]

[[[
Fix paths & command prompts for OS/2 by re-using WIN32 #ifdef's

* subversion/libsvn_subr/dirent_uri.c
* subversion/libsvn_subr/io.c
* subversion/libsvn_subr/prompt.c
* subversion/libsvn_ra_local/split_url.c
* subversion/libsvn_fs_fs/fs_fs.c
  (various): Use WIN32 code for paths with drive letters and command 
prompts
]]]


-- 
Cheers,

Paul.

begin 666 svn-paths.diff
m26y...@z('-U8G9E6=W
M:6...@*b\-"BLC96YD:6...@+rh@5TE.,S(@;W(@0WEG=VEN(&]R($]3+S(@*B\-
M"B`@("`@("`@("D-"B`@("`...@+2ul96x[#0h@#0I`0"`M,S$R+#<@*S,Q,BPW
M($!`#0H@("`@("`@("![#0H@("`@("`@("`@("\J($YO;W`@'0[#0H@("`@("`@("`@(&-A;F]N7W-E9VUE;G1S*RL[#0H@("`@("`@("!]
M#0HM(V5N9&EF("\J(%=)3C,R(&]R($-Y9W=I;B`J+PT**R-E;F1I9B`O*B!7
M24XS,B!O6=W:6X@;W(@3U,O,B`J+PT*("`@("`@(&5L6=W:6X@
M;W(@3U,O,B`J+PT*("`@("`@("`@("`...@*0t*("`@("`@("`@>PT*("`@("`@
M("`@("!I9B`H<&%T:#);:5T@/3T@)r\g*0t*...@+38r,"PY("LV,C`L.2!`
M0`T*("`@<&%T:#%?;&5N(#T@7!E(#T]('1Y<&5?9&ER96YT*2`F)B!P871H
M,5MP871H,5]l...@+2`q72`]/2`G.B6=W:6X@;W(@3U,O
M,B`J+PT*("`@("`@('Q\("AP871H,EMP871H,5]L96Y=(#T]("6=W:6...@86yd($]3+S(L(&)O
M=&@@+R]D6=W:6X@;W(@3U,O,B`J+PT*(`T*("`@2!A('-E<&%R871O6=W:6X@;W(@
M3U,O,B`J+PT*("`@("`@("`...@*0t*("`@("`@("`@("!A9&1?6=W:6X@;W(@3U,O,B`J+PT*("`@("`@("`...@*0t*("`@("`@("`@("!A9&1?
M6=W:6X@;W,@3U,O,B`J+PT*(`T*("`@6=W:6...@*b\-
M"BLC96YD:6...@+rh@5TE.,S(@;W(@0WEG=VEN(&]R($]3+S(@*B\-"B`-"B`@
M(')E='5R;B!DPT*("`@("`@("\J($EF('1H:7,@:7,@82!F
M:6QE('5R;"P@<'1R(&YO=R!P;VEN=',@=&\...@=&AE('1H:7)D("2D-"D!`("TW-SDL,3...@*s2!W:71H('!E2!F86EL(&]N(%=I;C,r...@5v4@
M;F5E9"!A#0HK("`O*B`C(R,@1DE8344Z(&%P2!T:&4...@8w5r"!C86QL#0HK("`O*B!/;B!7:6YD;W=S("8...@3u,O,BP@:G5S
M="!s...@=&AE(&9I;&4...@871t"!C86QL(&]U&5C=71A8FQE+`T*("`@("`@
M("`@("`@("`@("`@("`@("`@("`@(&EG;F]R95]E;F]E;G0L('!O;VPI.PT*
M("-E;'-E#0I`0"`M,34P,2PW("LQ-3`Q+#<@0$`-"B`@("`@("`@("`@("`@
M("`@("`@("`@("`@(&-O;G-T(&-H87(@*G!A=&@L#0H@("`@("`@("`@("`@
M("`@("`@("`@("`@("!A<')?<&]O;%]T("IP;V]L*0T*('L-"BTC:6...@9&5F
M:6YE9"A!4%)?2$%37U5315(I("8F("%D969I;F5D*%=)3C,R*0T**R-I9B!D
M969I;F5D*$%04E](05-?55-%4BD@)B8@(61E9FEN960H5TE.,S(I("8F(61E
M9FEN960H7U]/4S)?7RD-"B`@(&%P2!O;B!7:6YD;W=S+"!B96-A=7-E#0H@
M("`@("!7:6YD;W=S(&1O97,@;F]T(&QE="!U2!F:6QE#H@2D-"D!`("TW-2PX("LW-2PX($!`#0H@
M#0H@("`O*B!$=7!L:6-A=&4...@=&AE(%523"P@2!H879E('1O('-K:7...@=&AE(&QE861I;F<@+R!I9B!T:&4-
M"BLC:6...@9&5F:6YE9"A724XS,b...@?'p...@9&5F:6YE9"A?7T-91U=)3E]?*2!\
M?"!D969I;F5D("A?7T]3,e]?*0t*...@+rh@3...@5ven9&]W2D-"D!`("TU-3`X+#<@*S4U,#...@l."!`
M0`T*("`@("`@("`@("`@("`@("`@("`@(&-O;G-T(&-H87(@*G!E

Re: svn commit: r957094 - in /subversion/trunk: ./ subversion/include/ subversion/libsvn_client/ subversion/libsvn_fs*/ subversion/libsvn_ra*/ ...

[Arfrever Frehtes Taifersar Arahesis]

2010-06-24 18:35:21 Daniel Shahaf napisał(a):
> C. Michael Pilato wrote on Wed, 23 Jun 2010 at 22:43 -:
> > Daniel Shahaf wrote:
> > >> -  SVN_ERR(svn_ra_svn_write_cmd(conn, pool, "get-locks", "c", path));
> > >> +  /* Figure out the repository abspath from PATH. */
> > >> +  abs_path = svn_path_url_add_component2(sess->url, path, pool);
> > >> +  SVN_ERR(svn_ra_get_path_relative_to_root(session, &abs_path,
> > >> +   abs_path, pool));
> > > 
> > > I think this change means that, in build.conf, libsvn_ra should have
> > > been added as a dependency to [libsvn_ra_svn].  (This patch added it only
> > > to [svnserve].)
> > > 
> > > Unless objections, I'll make this change (while also committing the
> > > ra_svn protocol bits noted on IRC and in the issue).
> > 
> > Fine with me.  (The change I made was sufficient to fix the problem I was
> > seeing in my build.)
> > 
> 
> Looking further, the patch added svn_ra_get_path_relative_to_root() to
> all network-based RA layers.  However, when I try to add libsvn_ra in
> build.conf as suggested above, I just get errors from configure/make
> about circular dependencies :-(
> 
> I'm not sure what's going on here.  But if it breaks in the future,
> hopefully this thread is going to be useful...

This revision breaks building with --enable-disallowing-of-undefined-references
option passed to `configure`.

cd subversion/libsvn_ra_svn && /usr/bin/libtool --tag=CC --silent --mode=link 
x86_64-pc-linux-gnu-gcc  -march=core2 -pipe -O2   -pthread
-Werror=implicit-function-declaration  
-Wl,-O1,--as-needed,--gc-sections,--hash-style=gnu,--sort-common   
-L/usr/lib64/qt4  -rpath /usr/lib64 -Wl,--no-undefined -o libsvn_ra_svn-1.la  
client.lo cram.lo cyrus_auth.lo editorp.lo internal_auth.lo marshal.lo 
streams.lo version.lo ../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la -laprutil-1 -lapr-1 -lsasl2 
.libs/client.o: In function `ra_svn_get_locks':
client.c:(.text+0x7ee): undefined reference to 
`svn_ra_get_path_relative_to_root'
collect2: ld returned 1 exit status
make: *** [subversion/libsvn_ra_svn/libsvn_ra_svn-1.la] Error 1

I suggest to create libsvn_ra_util library (similar to libsvn_fs_util).
The code of svn_ra_get_path_relative_to_root() would be moved to
svn_ra__get_path_relative_to_root(), which would be defined in libsvn_ra_util.
libsvn_ra and libsvn_ra_svn would be linked against libsvn_ra_util.
libsvn_ra_svn would use svn_ra__get_path_relative_to_root().
svn_ra_get_path_relative_to_root() would be defined in libsvn_ra and would
wrap svn_ra__get_path_relative_to_root().

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.

Stalish downloads still on Tigris

[Jack Repenning]

It turns out that there are still quite a few folks downloading the rather 
stale-ish binary packages still stored on Tigris (Subversion installers and 
language bindings). We see around 40,000 downloads of these files per week, 
even though the newest is version 1.6.6. This is probably mostly confusion. I 
wonder if we shouldn't do something to un-confuse all these people?

What I'd propose would be:
1. move these packages to some other directory, that a bit more clearly shows 
their status (such as the existing "Windows Archive" one)
2. Put something (banner note, or URL-reference, something like that) into the 
folder to direct lost wanderers to packages.html or similar.

Sound reasonable? Additional thoughts? I'm happy to do the work.

Background:

There are, of course, other places with newer packages available. I don't 
really know why people keep downloading the new ones (and non-trivial numbers 
are still downloading Really Old Ones, even back into "releases" 0.X.X). A few 
of these downloads are probably people who know what they're doing -- testing 
against old versions, for example, to isolate when a problem first arose. But 
40K/week? I don't think so!

Mark Phippard and DJ Heap both suspect these are, fundamentally, some sort of 
confusion: people think Tigris is "the official source," or something like 
that. I had thought there might be some deeper reason, such as preferring the 
packaging format, but they talked me out of that.


-==-
Jack Repenning
jackrepenn...@tigris.org
Domain Administrator
http://www.tigris.org

Re: [PATCH] Let "svn blame" truncate long author names to keep the column width fixed to 10 characters

[Johan Corveleyn]

On Thu, Jun 24, 2010 at 1:47 PM, Daniel Shahaf  wrote:
> You truncate the author name even in 'svn blame -v' --- is that per the
> previous thread's concensus too?  (Personally I lean towards not
> truncating with -v.)

Thanks for the feedback.

I didn't consider that -v would have to be handled differently, but I
see your point (verbose may imply not to drop any information for the
sake of formatting). The previous thread didn't talk about "blame -v",
just "blame" in general, so I thought the consensus of the thread
applied to all blame output, whether -v or regular. But maybe that was
not the intent.

I don't really have a preference one way or the other. I never use
"blame -v" from the command line (and it wasn't really my personal
problem anyway, I just took it on to get some exercise in svn hacking
;). So I'll let you guys decide ...

Cheers,
Johan

>> > [1] http://svn.haxx.se/dev/archive-2010-04/0463.shtml

Re: svn commit: r957587 - in /subversion/trunk/subversion: libsvn_ra_svn/client.c libsvn_ra_svn/protocol svnserve/serve.c

[C. Michael Pilato]

Daniel Shahaf wrote:
> danie...@apache.org wrote on Thu, 24 Jun 2010 at 18:52 -:
>> Modified: subversion/trunk/subversion/svnserve/serve.c
>> URL: 
>> http://svn.apache.org/viewvc/subversion/trunk/subversion/svnserve/serve.c?rev=957587&r1=957586&r2=957587&view=diff
>> ==
>> --- subversion/trunk/subversion/svnserve/serve.c (original)
>> +++ subversion/trunk/subversion/svnserve/serve.c Thu Jun 24 15:52:26 2010
>> @@ -2577,7 +2577,7 @@ static svn_error_t *get_locks(svn_ra_svn
>>apr_hash_t *locks;
>>apr_hash_index_t *hi;
>>  
>> -  SVN_ERR(svn_ra_svn_parse_tuple(params, pool, "c?w", &path, &depth_word));
>> +  SVN_ERR(svn_ra_svn_parse_tuple(params, pool, "c?(?w)", &path, 
>> &depth_word));
>>  
>>depth = depth_word ? svn_depth_from_word(depth_word) : svn_depth_infinity;
> 
> Need to check here that depth >= svn_depth_empty.  (otherwise
> libsvn_repos would assert).
> 
> CCing myself so I don't forget.

I just double-checked mod_dav_svn -- it returns a graceful error on a bad
depth.  I must have overlooked this in svnserve.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r957587 - in /subversion/trunk/subversion: libsvn_ra_svn/client.c libsvn_ra_svn/protocol svnserve/serve.c

[Daniel Shahaf]

danie...@apache.org wrote on Thu, 24 Jun 2010 at 18:52 -:
> Modified: subversion/trunk/subversion/svnserve/serve.c
> URL: 
> http://svn.apache.org/viewvc/subversion/trunk/subversion/svnserve/serve.c?rev=957587&r1=957586&r2=957587&view=diff
> ==
> --- subversion/trunk/subversion/svnserve/serve.c (original)
> +++ subversion/trunk/subversion/svnserve/serve.c Thu Jun 24 15:52:26 2010
> @@ -2577,7 +2577,7 @@ static svn_error_t *get_locks(svn_ra_svn
>apr_hash_t *locks;
>apr_hash_index_t *hi;
>  
> -  SVN_ERR(svn_ra_svn_parse_tuple(params, pool, "c?w", &path, &depth_word));
> +  SVN_ERR(svn_ra_svn_parse_tuple(params, pool, "c?(?w)", &path, 
> &depth_word));
>  
>depth = depth_word ? svn_depth_from_word(depth_word) : svn_depth_infinity;

Need to check here that depth >= svn_depth_empty.  (otherwise
libsvn_repos would assert).

CCing myself so I don't forget.

>full_path = svn_uri_join(b->fs_path->data,
> 
> 
> 

[PATCH] Add explicit protocol version number to HTTP OPTIONS response.

[C. Michael Pilato]

Since Subversion 1.5, our HTTP clients always make an OPTIONS exchange with
the server.  The OPTIONS response originally carried information about
supported server features by way of naming those features individually.  In
Subversion 1.7, we're expanding our horizons a bit by implementing a whole
new customized WebDAV implementation, complete with magical and mystical
private DAV resources which can be queried more directly than the former
negotiate-a-resource-target system allowed.  For now we're letting the
presence of a header which names a particular such resource (the "me
resource") carry the information that the server can speak this new
protocol.  But I'm wondering if at this point -- now that we've embraced the
idea of *not* embracing the WebDAV standard quite so firmly --  we wouldn't
be best served by adding an explicit protocol version number to the OPTIONS
response?  A single number can carry a multitude of information far more
efficiently than a potentially boundless list of individual support strings.

(I'm thinking about these things because our current HTTPv2 is not the end
of our development of this protocol.  We've talked quite a bit lately about
extending our POST handler in various ways, for example.)

There are, to my knowledge, two downsides to this:

1. third-party server implementations of our protocol would need to support
the whole of our latest protocol before claiming they support any of it.  To
my knowledge there are a couple of such server implementations (WANdisco's
SVN-J and another company's IIS plugin).

2. to the degree that we wish to support not-yet-released server versions
(for our dev work, for example), we'd be bumping the protocol version number
just as often as if we'd added individual feature negotiation strings.  That
means more code churn with less protocol-level transparency about what's
changed.

I think I still like the idea, if only because it disentangles "server
features" from "server vocabulary".  But I'm not convinced enough to commit
the attached patch.  So, as I'm wont to do, I'll use this last as my patch
backup system.  :-)

Thoughts?  Concerns?  Greg Steins?

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
Add an explicit protocol format number to the HTTP OPTIONS response.

* subversion/include/svn_dav.h
  (SVN_DAV_PROTOCOL_VERSION_HEADER, SVN_DAV_PROTOCOL_VERSION_LATEST,
   SVN_DAV_MIN_HTTPV2_VERSION): New #defines.

* subversion/libsvn_ra_neon/ra_neon.h
  (svn_ra_neon__session_t): Add 'protocol_version' member, and
rejigger the formatting of nearby comments and such.
  (SVN_RA_NEON__HAVE_HTTPV2_SUPPORT): Removed.  All consumers updated
to instead use...
  (SVN_RA_NEON__IS_VERSION_SUPPORTED): ... this new macro.

* subversion/libsvn_ra_neon/session.c
  (svn_ra_neon__open): Set the default value of the session baton's
new protocol_version member.

* subversion/libsvn_ra_neon/options.c
  (parse_capabilities): Look for the new SVN-Protocol-Version header,
and store its value in the session baton.  If we see a "me
resource" but not a protocol version, store the minimal "HTTP-v2-ish"
version in the session baton.

* subversion/libsvn_ra_neon/fetch.c,
* subversion/libsvn_ra_neon/get_dated_rev.c
  Update consumer of SVN_RA_NEON__HAVE_HTTPV2_SUPPORT() to use
  SVN_RA_NEON__IS_VERSION_SUPPORTED() instead.

* subversion/libsvn_ra_serf/ra_serf.h
  (svn_ra_serf__session_t): Add 'protocol_version' member, and
rejigger the formatting of nearby comments and such.
  (SVN_RA_SERF__HAVE_HTTPV2_SUPPORT): Removed.  All consumers updated
to instead use...
  (SVN_RA_SERF__IS_VERSION_SUPPORTED): ... this new macro.

* subversion/libsvn_ra_serf/serf.c
  (svn_ra_serf__open): Set the default value of the session baton's
new protocol_version member.

* subversion/libsvn_ra_serf/options.c
  (capabilities_headers_iterator_callback): Look for the new
SVN-Protocol-Version header, and store its value in the session baton.
  (options_response_handler): If we got a "me resource" in the
headers, but not a protocol version, store the minimal "HTTP-v2-ish"
version in the session baton.

* subversion/libsvn_ra_serf/commit.c,
* subversion/libsvn_ra_serf/merge.c,
* subversion/libsvn_ra_serf/property.c,
* subversion/libsvn_ra_serf/update.c,
* subversion/libsvn_ra_serf/util.c
  Update consumers of SVN_RA_SERF__HAVE_HTTPV2_SUPPORT() to use
  SVN_RA_SERF__IS_VERSION_SUPPORTED() instead.

--This line, and those below, will be ignored--
Index: subversion/include/svn_dav.h
===
--- subversion/include/svn_dav.h(revision 957402)
+++ subversion/include/svn_dav.h(working copy)
@@ -96,10 +96,16 @@
  * repository.  */
 #define SVN_DAV_REPOS_UUID_HEADER "SVN-Repository-UUID"
 
-/** Presence of this in a DAV header in an OPTIONS response indicates
- * that the server speaks HTTP protocol v2.  This header provides an
- * opaque UR

RE: svn commit: r957608 - in /subversion/trunk/subversion/libsvn_client: info.c status.c

[Bert Huijben]

> -Original Message-
> From: hwri...@apache.org [mailto:hwri...@apache.org]
> Sent: donderdag 24 juni 2010 18:20
> To: comm...@subversion.apache.org
> Subject: svn commit: r957608 - in
> /subversion/trunk/subversion/libsvn_client: info.c status.c
> 
> Author: hwright
> Date: Thu Jun 24 16:19:42 2010
> New Revision: 957608
> 
> URL: http://svn.apache.org/viewvc?rev=957608&view=rev
> Log:
> Follow up to r957094 by updating callers to the new API.
> 
> * subversion/libsvn_client/status.c
>   (reporter_finish_report),
> * subversion/libsvn_client/info.c
>   (svn_client_info3): Use svn_ra_get_locks2().

These callers should both be fixed to supply a reduced depth 
(svn_client_statusX() and svn_client_infoX() both receive a limiting depth from 
their callers). And you just removed the warning to help us remind that we 
should that.

I think you should either fix this to supply the right (limiting) depth, or 
revert this commit to get the reminder back in place.

Bert

Re: Antwort: Re: dangerous implementation of rep-sharing cache for fsfs

[Greg Hudson]

On Thu, 2010-06-24 at 11:29 -0400, michael.fe...@evonik.com wrote:
> We must ensure that the data in the repository is, without any concerns, 
> the data we have once measured or written. 

You do realize that the probability of data corruption due to faulty
hardware is much, much more likely than the probability of corruption
due to a rep-sharing SHA-1 collision, right?

Re: svn commit: r957094 - in /subversion/trunk: ./ subversion/include/ subversion/libsvn_client/ subversion/libsvn_fs*/ subversion/libsvn_ra*/ ...

[Daniel Shahaf]

C. Michael Pilato wrote on Wed, 23 Jun 2010 at 22:43 -:
> Daniel Shahaf wrote:
> >> -  SVN_ERR(svn_ra_svn_write_cmd(conn, pool, "get-locks", "c", path));
> >> +  /* Figure out the repository abspath from PATH. */
> >> +  abs_path = svn_path_url_add_component2(sess->url, path, pool);
> >> +  SVN_ERR(svn_ra_get_path_relative_to_root(session, &abs_path,
> >> +   abs_path, pool));
> > 
> > I think this change means that, in build.conf, libsvn_ra should have
> > been added as a dependency to [libsvn_ra_svn].  (This patch added it only
> > to [svnserve].)
> > 
> > Unless objections, I'll make this change (while also committing the
> > ra_svn protocol bits noted on IRC and in the issue).
> 
> Fine with me.  (The change I made was sufficient to fix the problem I was
> seeing in my build.)
> 

Looking further, the patch added svn_ra_get_path_relative_to_root() to
all network-based RA layers.  However, when I try to add libsvn_ra in
build.conf as suggested above, I just get errors from configure/make
about circular dependencies :-(

I'm not sure what's going on here.  But if it breaks in the future,
hopefully this thread is going to be useful...

Antwort: Re: dangerous implementation of rep-sharing cache for fsfs

[michael . felke]

Hello,

sorry, but out E-mailing system doesn't support the usual way of 
citating the message replied to.

First, we are using svn in chem. laboratory to save, archive and 
version data and methods of our measurements. 
We must ensure that the data in the repository is, without any concerns, 
the data we have once measured or written. 
So, only the totally reliable Solution for the rep-sharing cache 
would be acceptable to us.

Yes, and i am interested in helping you to improve Subversion 
by writing needed code. But i am not sure that i will be able to
compile subversion completely here at work, i could try.
Perhaps someone is willing to help me testing my code?

Thanks for the hint to svn_fs_fs__set_rep_reference, 
because it didn't expected the additional checks to be there.
I locked there, but couldn't get at a first glance,
 when this check is performed. I will go deeper later.

I think it's better to add an check on md5 than any on part of fulltext,
because it's calculated on the hole data, too.
But is isn't imported to me, 
it only reduces the risk it does not eliminate it.

Greetings

P.S. I am also sorry for the signature, we are recommended to use.

Michael Felke
Telefon +49 2151 38-1453
Telefax +49 2151 38-1094
michael.fe...@evonik.com
Evonik Stockhausen GmbH
Bäkerpfad 25
47805 Krefeld
http://www.evonik.com

Geschäftsführung: Gunther Wittmer (Sprecher), Willibrord Lampen

Sitz der Gesellschaft: Krefeld
Registergericht: Amtsgericht Krefeld; Handelsregister HRB 5791

This e-mail transmission, and any documents, files or previous e-mail 
messages attached to it may contain information that is confidential or 
legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that you must not read this transmission and that any disclosure, 
copying, printing, distribution or use of any of the information contained 
in or attached to this transmission is STRICTLY PROHIBITED. If you have 
received this transmission in error, please immediately notify the sender 
by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you. 





Daniel Shahaf 
24.06.2010 16:38
 
An: Julian Foad 
Kopie:  michael.fe...@evonik.com, dev@subversion.apache.org
Thema:  Re: dangerous implementation of rep-sharing cache for fsfs


Julian Foad wrote on Thu, 24 Jun 2010 at 17:21 -:
> I am not sure whether the "representation" whose SHA-1 sum is stored is
> ever an exact copy of the user's file.  If it is - if it does not
> include an extra header and is not stored in a delta format - then the

That is not the case:

[[[
A representation begins with a line containing either "PLAIN\n" or
"DELTA\n" or "DELTA   \n", where , ,
and  give the location of the delta base of the representation
and the amount of data it contains (not counting the header or
trailer).  If no base location is given for a delta, the base is the
empty stream.  After the initial line comes raw svndiff data, followed
by a cosmetic trailer "ENDREP\n".
]]]

So, there are header, trailer, and it's possibly deltified or 
self-deltified.

> chance of collision would depend directly on the content of the user's
> files.  If that is the case, it *might* be advisable to disable the
> rep-cache feature if you are storing files that have a higher than usual
> chance of SHA-1 collisions - data files for SHA-1 research, for example.
> 
> We should find out the answer to that question before going further.
> 
> 
> > Indeed, the number of hash collisions is only finite for a given file 
> > size, but is still increasing dramatically with the file size.
> > So additional checking of the file size helps but is not a completely 
> > satisfying solution.
> > 
> > The number of undetected hash collisions could be reduced easily by 
also 
> > checking the md5-checksum, the size and the expanded-size.
> 

Check svn_fs_fs__set_rep_reference in rep-cache.c; we already assert
that the size and expanded size match.

It's indeed possible to also use md5 there.  Another option is to use
practically any statistic about the fulltext: the first N bytes, the
number of '#' characters, ...

> True.  This approach could be beneficial if there are cases where the
> perfect solution (below) is not feasible.
> 
> > To make this feature totally reliable, a complete comparison of the 
files 
> > content with the content of the old representation found, is necessary
> 
> Yes, it would be good if Subversion could do this extra check.  Would
> you be interested in helping to improve Subversion by writing code to do
> this?  If so, you will be very welcome and we will try to help you.
> 

+1 from me too.

> (I recall reading about an option in Git (?) to switch on full-text
> comparisons to check for SHA-1 collisions.  I can't find a reference to
> it now.)
> 
> 
> Regards,

Re: dangerous implementation of rep-sharing cache for fsfs

[Daniel Shahaf]

Julian Foad wrote on Thu, 24 Jun 2010 at 17:21 -:
> I am not sure whether the "representation" whose SHA-1 sum is stored is
> ever an exact copy of the user's file.  If it is - if it does not
> include an extra header and is not stored in a delta format - then the

That is not the case:

[[[
A representation begins with a line containing either "PLAIN\n" or
"DELTA\n" or "DELTA   \n", where , ,
and  give the location of the delta base of the representation
and the amount of data it contains (not counting the header or
trailer).  If no base location is given for a delta, the base is the
empty stream.  After the initial line comes raw svndiff data, followed
by a cosmetic trailer "ENDREP\n".
]]]

So, there are header, trailer, and it's possibly deltified or self-deltified.

> chance of collision would depend directly on the content of the user's
> files.  If that is the case, it *might* be advisable to disable the
> rep-cache feature if you are storing files that have a higher than usual
> chance of SHA-1 collisions - data files for SHA-1 research, for example.
> 
> We should find out the answer to that question before going further.
> 
> 
> > Indeed, the number of hash collisions is only finite for a given file 
> > size, but is still increasing dramatically with the file size.
> > So additional checking of the file size helps but is not a completely 
> > satisfying solution.
> > 
> > The number of undetected hash collisions could be reduced easily by also 
> > checking the md5-checksum, the size and the expanded-size.
> 

Check svn_fs_fs__set_rep_reference in rep-cache.c; we already assert
that the size and expanded size match.

It's indeed possible to also use md5 there.  Another option is to use
practically any statistic about the fulltext: the first N bytes, the
number of '#' characters, ...

> True.  This approach could be beneficial if there are cases where the
> perfect solution (below) is not feasible.
> 
> > To make this feature totally reliable, a complete comparison of the files 
> > content with the content of the old representation found, is necessary
> 
> Yes, it would be good if Subversion could do this extra check.  Would
> you be interested in helping to improve Subversion by writing code to do
> this?  If so, you will be very welcome and we will try to help you.
> 

+1 from me too.

> (I recall reading about an option in Git (?) to switch on full-text
> comparisons to check for SHA-1 collisions.  I can't find a reference to
> it now.)
> 
> 
> Regards,
> - Julian
> 
> 
> 

Re: dangerous implementation of rep-sharing cache for fsfs

[Julian Foad]

michael.fe...@evonik.com wrote:
> [The new representation caching in 1.6] could save us a lot of disk space
> on the server [...].
> 
> But unfortunately it seems we could not use it :-(
> Because after what the source code of rep.cache.c and fs_fs.c in 
> libsvn_fs_fs looks to me, the mechanism to find an already existing 
> representation is only relaying on the sha1-checksum.
> Due to the possibility of hash collisions it's not enough to ensure that 
> the found old representation is really an duplicate of the new one.
> An undetected hash collision would result in a file with a totally wrong 
> contents.
> 
> sha1 has been developed to detected modifications in a file and ensure 
> that it's likely impossible to generate the same sha1-checksum be only 
> modifying a file. 
> So it is good to use it whether a file has been modified.
> But it's not designed to check if two different files could possibly the 
> same. 
> There are always infinity numbers of independent files generating the same 
> checksum.

You are right that there is the theoretical possibility of a different
file having the same SHA-1 and therefore being incorrectly stored.

When using real-life data, the statistical chance is so incredibly tiny
that most people who have tried to estimate the chance do not expect
that it will ever happen.

I am not sure whether the "representation" whose SHA-1 sum is stored is
ever an exact copy of the user's file.  If it is - if it does not
include an extra header and is not stored in a delta format - then the
chance of collision would depend directly on the content of the user's
files.  If that is the case, it *might* be advisable to disable the
rep-cache feature if you are storing files that have a higher than usual
chance of SHA-1 collisions - data files for SHA-1 research, for example.

We should find out the answer to that question before going further.


> Indeed, the number of hash collisions is only finite for a given file 
> size, but is still increasing dramatically with the file size.
> So additional checking of the file size helps but is not a completely 
> satisfying solution.
> 
> The number of undetected hash collisions could be reduced easily by also 
> checking the md5-checksum, the size and the expanded-size.

True.  This approach could be beneficial if there are cases where the
perfect solution (below) is not feasible.

> To make this feature totally reliable, a complete comparison of the files 
> content with the content of the old representation found, is necessary

Yes, it would be good if Subversion could do this extra check.  Would
you be interested in helping to improve Subversion by writing code to do
this?  If so, you will be very welcome and we will try to help you.

(I recall reading about an option in Git (?) to switch on full-text
comparisons to check for SHA-1 collisions.  I can't find a reference to
it now.)


Regards,
- Julian

Re: Getting delta content length

[Ramkumar Ramachandra]

Hi,

> IIRC, Subversion is calculating that delta on the fly, so it can't exactly
> hand you up-front the length thereof.  Could you use a temporary file on
> disk (and a stat() call for the filesize) instead of in-memory storage as
> your go-between?

I see. Writing to filesystem and measuring size is inefficient as
well, but I suppose I could do that if there's no other alternative.

-- Ram

Re: Getting delta content length

[C. Michael Pilato]

Ramkumar Ramachandra wrote:
> Hi,
> 
> We're working on a project to replay revisions using the replay API
> and dump a deltified dumpfile to stdout on-the-fly without using a
> filesystem backing. Althought the md5sum seems to be available through
> svn_txdelta_apply, the length of the delta doesn't seem to be. Without
> this length, we cannot generate a valid dumpfile (since the parser
> needs the content length information) - the current workaround is to
> load the whole stream into memory and measure its length, but this is
> highly inefficient. Is there any other way?

IIRC, Subversion is calculating that delta on the fly, so it can't exactly
hand you up-front the length thereof.  Could you use a temporary file on
disk (and a stat() call for the filesize) instead of in-memory storage as
your go-between?

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Getting delta content length

[Ramkumar Ramachandra]

Hi,

We're working on a project to replay revisions using the replay API
and dump a deltified dumpfile to stdout on-the-fly without using a
filesystem backing. Althought the md5sum seems to be available through
svn_txdelta_apply, the length of the delta doesn't seem to be. Without
this length, we cannot generate a valid dumpfile (since the parser
needs the content length information) - the current workaround is to
load the whole stream into memory and measure its length, but this is
highly inefficient. Is there any other way?

-- Ram

Re: [Patch] Support OS/2

[Julian Foad]

Paul Smedley wrote:
> I've been building Subversion on OS/2 for some time, and figured it was 
> time to request to get the patches incorporated in the main distribution.

Hi Paul.  Thanks - we'd be delighted to receive your changes to make
Subversion work on OS/2.

> The current diff, based on 1.6.12 is attached.

> Mostly, it's changes to use some of the Win32 code for drive letters, etc.

As well as what Bert just said, I'd ask you to help us out in a couple
of other ways.  First, please split the patch into the different logical
changes - at a quick glance I can see changes to make Windows-style
paths work, changing some config file preferences, and changing the
svnserve default connection mode - and send a separate patch for each.

Please write a log message that says what's changing functionally and
why, for each patch, in the form described in
.  Very 
few of us know OS/2 so we'll need your expertise to help us understand the 
changes.

Thank you.
- Julian

RE: [Patch] Support OS/2

[Bert Huijben]

> -Original Message-
> From: Paul Smedley [mailto:p...@smedley.id.au]
> Sent: donderdag 24 juni 2010 15:04
> To: dev@subversion.apache.org
> Subject: [Patch] Support OS/2
> 
> Hi All,
> 
> I've been building Subversion on OS/2 for some time, and figured it was
> time to request to get the patches incorporated in the main
> distribution.
> 
> The current diff, based on 1.6.12 is attached.
> 
> Mostly, it's changes to use some of the Win32 code for drive letters,
> etc.

Huge chunks of this code have been rewritten on trunk. (E.g. the dirent code
and some parts of io.c). Can you update this patch to work against trunk?

The path changes look ok. Your  changes in io.c use '//'-style comments and
most likely break on other operating systems.

E.g. 
>/* If the file is in a memory filesystem, fsync() may return
>   EINVAL.  Presumably the user knows the risks, and we can just
>   ignore the error. */
> -  if (rv == -1 && APR_STATUS_IS_EINVAL(apr_get_os_error()))
> +//  if (rv == -1 && APR_STATUS_IS_EINVAL(apr_get_os_error()))
> +   if (rv != 0 && rv==EINVAL)
>  return SVN_NO_ERROR;

Changes the check from
#define APR_STATUS_IS_EINVAL(s) ((s) == APR_EINVAL \
|| (s) == APR_OS_START_SYSERR + ERROR_INVALID_ACCESS \
|| (s) == APR_OS_START_SYSERR + ERROR_INVALID_DATA \
|| (s) == APR_OS_START_SYSERR + ERROR_INVALID_FUNCTION \
|| (s) == APR_OS_START_SYSERR + ERROR_INVALID_HANDLE \
|| (s) == APR_OS_START_SYSERR + ERROR_INVALID_PARAMETER \
|| (s) == APR_OS_START_SYSERR + ERROR_NEGATIVE_SEEK)

To just checking for APR_EINVAL on Windows.


We don't keep the old code as comments in our code; we use a version control
system to look at the old code ;-)

>if (rv == -1)
>  return svn_error_wrap_apr
> -  (apr_get_os_error(), _("Can't flush file to disk"));
> +   (rv, _("Can't flush file to disk"));
> +//  (apr_get_os_error(), _("Can't flush file to disk"));

This will return error code -1 (Undefined behavior), where it used to give
the os error.
(Similar cases in a few places)


Bert

[Patch] Support OS/2

[Paul Smedley]

Hi All,

I've been building Subversion on OS/2 for some time, and figured it was 
time to request to get the patches incorporated in the main distribution.


The current diff, based on 1.6.12 is attached.

Mostly, it's changes to use some of the Win32 code for drive letters, etc.

Cheers,

Paul.


subversion-1.6.12.diff
Description: application/diff

Re: [PATCH] Let "svn blame" truncate long author names to keep the column width fixed to 10 characters

[Daniel Shahaf]

You truncate the author name even in 'svn blame -v' --- is that per the 
previous thread's concensus too?  (Personally I lean towards not 
truncating with -v.)

Daniel
(no need to re-send for this)

Johan Corveleyn wrote on Thu, 24 Jun 2010 at 14:25 -:
> Ping. This patch hasn't gotten feedback nor commits ...
> 
> Johan
> 
> On Fri, Jun 18, 2010 at 10:22 PM, Johan Corveleyn  wrote:
> > Hi devs,
> >
> > Here is another (trivial) patch for "svn blame", which was also
> > discussed in [1].
> >
> > [[[
> > Let "svn blame" truncate long author names to keep the column width
> > fixed to 10 characters.
> >
> > * subversion/svn/blame-cmd.c
> >  (print_line_info): Change the printf format to truncate author names
> >   to 10 characters.
> > ]]]
> >
> > Cheers,
> > --
> > Johan
> >
> > [1] http://svn.haxx.se/dev/archive-2010-04/0463.shtml
> >
> 
> 
> 
> 

Re: [PATCH] Let "svn blame" truncate long author names to keep the column width fixed to 10 characters

[Johan Corveleyn]

Ping. This patch hasn't gotten feedback nor commits ...

Johan

On Fri, Jun 18, 2010 at 10:22 PM, Johan Corveleyn  wrote:
> Hi devs,
>
> Here is another (trivial) patch for "svn blame", which was also
> discussed in [1].
>
> [[[
> Let "svn blame" truncate long author names to keep the column width
> fixed to 10 characters.
>
> * subversion/svn/blame-cmd.c
>  (print_line_info): Change the printf format to truncate author names
>   to 10 characters.
> ]]]
>
> Cheers,
> --
> Johan
>
> [1] http://svn.haxx.se/dev/archive-2010-04/0463.shtml
>



-- 
Johan

Re: revprop changes and hooks

[Daniel Shahaf]

C. Michael Pilato wrote on Fri, 18 Jun 2010 at 22:02 -:
> Daniel Shahaf wrote:
> > You mean, to extend the dav_db structure to hold that information?  If
> > that's possible, I suppose the only candidate for filling in that
> > information is db_open(), who can examine its dav_resource object.  But
> > does the dav_resource object contain the needed information?  Or do we
> > need the request_rec object for that?
> 
> Hrm, come to think of it, this might be something that isn't easy to do by
> merely extending the PROPPATCH request.  mod_dav may simply not give us
> enough information.  Is this something we need to employ HTTPv2 for?  (I
> truly don't know at this point.)

Update: after talking to Greg and Mike on IRC, the current plan is to
use db_store()'s ELEM parameter to access the PROPPATCH XML document
tree, before trying other approaches (HTTPv2, POST, etc).

Re: Ruby bindings don't work with 1.9 + patch

[Hyrum K. Wright]

Applied in r957507.  I noticed the patch was against 1.6.12, but it
applied cleanly to trunk.  In the future, please make patches against
trunk (and hopefully include a log message).

Should this be backported to the 1.6.x branch?

Cheers,
-Hyrum

On Wed, Jun 23, 2010 at 6:52 PM, Joe Rozner  wrote:
> Sorry about that, here is the patch file again as a .txt file.
>
> Joe Rozner
>
>
> On Jun 23, 2010, at 12:25 AM, Bert Huijben wrote:
>
>>> -Original Message-
>>> From: Joe Rozner [mailto:j...@deadbytes.net]
>>> Sent: woensdag 23 juni 2010 5:43
>>> To: dev@subversion.apache.org
>>> Subject: Ruby bindings don't work with 1.9 + patch
>>>
>>> The ruby bindings were having issues being used with Ruby 1.9 due to
>>> changes in the case syntax. Here is a patch file that fixes the issue.
>>>
>>> Joe Rozner
>>> j...@deadbytes.net
>>
>>       Hi Joe,
>>
>> Your patch didn't reach the list. Can you try resending your patch?
>> (Possibly with a .txt extension)
>>
>> I can't check your patch now to check if it has one, but adding a log
>> message to your patch (either in the patch file or in the mail) makes
>> reviewing much easier.
>>
>> Thanks,
>>       Bert
>>
>
>
>

dangerous implementation of rep-sharing cache for fsfs

[michael . felke]

Excuse me, but i original wrote the following E-Mail to Hyrum K. Wright 
directly,
because I wasn't used to the guidelines of the subversion project.

- Weitergeleitet von Michael Felke/AN/Stockhausen/DE am 24.06.2010 
11:09 -


Michael Felke
23.06.2010 14:07
 
An: hwri...@tigris.org
Kopie: 
Thema:  subversion Issue 2286: rep-sharing cache for fsfs

Hello Hyrum K. Wright,

sorry that i bother you with this directly, but i have no clue of work 
with the issue tracker.

I just started to checking the changes in 1.6 on possible problem, when 
updating our raw data repository to this version.
I found that the new representation caching would have an great impact on 
our site.

It could save us a lot of disk space on the server, because the software 
we are using, often generates file copies, witch are added as separate 
files.

But unfortunately it seems we could not use it :-(
Because after what the source code of rep.cache.c and fs_fs.c in 
libsvn_fs_fs looks to me, the mechanism to find an already existing 
representation is only relaying on the sha1-checksum.
Due to the possibility of hash collisions it's not enough to ensure that 
the found old representation is really an duplicate of the new one.
An undetected hash collision would result in a file with a totally wrong 
contents.

sha1 has been developed to detected modifications in a file and ensure 
that it's likely impossible to generate the same sha1-checksum be only 
modifying a file. 
So it is good to use it whether a file has been modified.
But it's not designed to check if two different files could possibly the 
same. 
There are always infinity numbers of independent files generating the same 
checksum.
Indeed, the number of hash collisions is only finite for a given file 
size, but is still increasing dramatically with the file size.
So additional checking of the file size helps but is not a completely 
satisfying solution.

The number of undetected hash collisions could be reduced easily by also 
checking the md5-checksum, the size and the expanded-size.
To make this feature totally reliable, a complete comparison of the files 
content with the content of the old representation found, is necessary

Yours sincerely

Michael Felke
Telefon +49 2151 38-1453
Telefax +49 2151 38-1094
michael.fe...@evonik.com
Evonik Stockhausen GmbH
Bäkerpfad 25
47805 Krefeld
http://www.evonik.com

Geschäftsführung: Gunther Wittmer (Sprecher), Willibrord Lampen

Sitz der Gesellschaft: Krefeld
Registergericht: Amtsgericht Krefeld; Handelsregister HRB 5791

This e-mail transmission, and any documents, files or previous e-mail 
messages attached to it may contain information that is confidential or 
legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that you must not read this transmission and that any disclosure, 
copying, printing, distribution or use of any of the information contained 
in or attached to this transmission is STRICTLY PROHIBITED. If you have 
received this transmission in error, please immediately notify the sender 
by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you. 

Re: How does the workqueues provide atomic updates, or do they?

[Daniel Näslund]

On Thu, Jun 24, 2010 at 09:20:22AM +0100, Philip Martin wrote:
> Daniel Näslund  writes:
> 
> > How are files installed during an update?
> > 
> > We acquire a write lock
> > We crawl the wc
> > We tell the repos about our state
> > The repo runs an editor
> >   open_root(): We set status to _status_incomplete
> > open_directory(): We set status t _status_incomplete.
> >   close_file(): We run the wq
> > close_directory(): We run the wq
> 
> close_directory will remove status_incomplete for the directory, see
> maybe_bump_dir_info.  At present it's a direct database operation but
> it may become part of the wq for the directory.
> 
> >   close_edit(): Remove status_incomplete
> > release write_lock
> >
> > What if we get interrupted?
> > 
> > We have this incoming change:
> >   M   A/B/lambda
> >   M   A/B/beta
> >
> > But we only process lambda and get cancelled before we start processing
> > beta. Then there's no wq started for beta. How does the wq know that the
> > update isn't complete?
> 
> The wq doesn't know or care.  All the wq knows is whether there are
> outstanding items.
> 
> > Or is the status that tells us that the update is
> > not complete? E.g. the workqueues provide write atomicity but it's the
> > status that tells us if the whole operation has succeded?
> 
> The status_incomplete remains on the directory.  It will remain until
> the user runs update successfully.
> 
> > I think it works like this:
> > --
> > * If the next operation tries to acquire a write lock it will fail and
> >   tell the user to run 'svn cleanup'
> > * svn_wc_cleanup() will run all remaining work items in the different
> >   workqueues (will be one queue when we have one db).
> 
> Yes.  Although note that pool cleanups attempt to run any outstanding
> wq so controlled cancel will often run any wq and remove locks, just
> leaving the incomplete status.

Ok. For update that would be update_editor.c::cleanup_dir_baton() that
gets registered in cleanup_dir_baton_child() with a call to
apr_pool_cleanup_kill(). (Just putting it here for reference).

> > * Something detects that the update is incomplete and resumes it *or*
> >   something detects that the update is incomplete and reverts what has
> >   been done so far.
> 
> No.  In future it may change but at present the user needs to invoke
> update to finish the operation.

Thanks for your answers!
Daniel

[WIP] #1957 'svn switch does not update keywords'

[Daniel Näslund]

Hi!

Is 'svn switch does not update keywords' a problem that needs solving?

Is the performance of this solution acceptable (traverse the entire wc
one more time after the editor drive)?

Alternatives? 
* Custom db-query that only returns the paths with matching property set
  on them. Could be used by 'svn pg -R' later on.
* Do the recording during the crawling of the wc. Saves us the extra
  traversal.

And why is it not working? :)

I'm translating the file in the WC back into Normal Form and then I
install it through the workqueue mecanism. It does get translated but
not to the current URL but to the previous.

[[[
Fix issue #1975 - 'svn switch does not update keywords'.

Only files affected by the switch gets keyword translation, possibly
making some $URL$ keywords incorrect. We do a complete traversal of
the WC to check for the files that have svn:keywords pristine props 
set and retranslate those files. */

* subversion/libsvn_wc/update_editor.c
  (reinstall_target_baton): New
  (reinstall_target_with_keywords): New.
  (close_edit): walk all children and call 
reinstall_target_with_keywords().
]]]

Daniel
Index: subversion/libsvn_wc/update_editor.c
===
--- subversion/libsvn_wc/update_editor.c(revision 957424)
+++ subversion/libsvn_wc/update_editor.c(arbetskopia)
@@ -5080,13 +5080,83 @@ close_file(void *file_baton,
   return SVN_NO_ERROR;
 }
 
+struct reinstall_target_baton
+{
+  svn_wc__db_t *db;
+  svn_cancel_func_t cancel_func;
+  void *cancel_baton;
 
+  /* ### Do we need a result_pool here? How is the apr pool cleanup handler
+   * configured? We need a pool with the handler activated in case we get
+   * cancelled. ### */
+};
+
+/* Reinstall target to assure svn:keywords expand correctly. */
+static svn_error_t *
+reinstall_target_with_keywords(const char *local_abspath, 
+   void *walk_baton,
+   apr_pool_t *scratch_pool)
+{
+  struct reinstall_target_baton *rtb = walk_baton;
+  apr_hash_t *props;
+  const char *tmptext;
+
+  SVN_DBG(("reinstall_target() %s\n", local_abspath));
+
+  SVN_ERR(svn_wc__get_pristine_props(&props, rtb->db, local_abspath,
+ scratch_pool, scratch_pool));
+
+  /* ### There must be a constant for svn:keywords somewhere, but where? */
+  if (props && apr_hash_get(props, "svn:keywords", APR_HASH_KEY_STRING))
+{
+  svn_skel_t *all_work_items;
+  svn_skel_t *work_item;
+
+  SVN_DBG(("svn:keywords found\n"));
+  SVN_ERR(svn_wc__internal_translated_file(&tmptext, local_abspath,
+   rtb->db, local_abspath,
+   SVN_WC_TRANSLATE_TO_NF
+   | 
SVN_WC_TRANSLATE_NO_OUTPUT_CLEANUP,
+   rtb->cancel_func,
+   rtb->cancel_baton,
+   scratch_pool, scratch_pool));
+
+  SVN_ERR(svn_wc__wq_build_file_install(&all_work_items, rtb->db,
+local_abspath,
+tmptext, /* install_from */
+TRUE, /* use_commit_times */
+TRUE, /* record_fileinfo */
+scratch_pool, scratch_pool));
+  SVN_ERR(svn_wc__wq_build_file_remove(&work_item, rtb->db, tmptext,
+   scratch_pool, scratch_pool));
+  all_work_items = svn_wc__wq_merge(all_work_items, work_item,
+scratch_pool);
+
+  /* ### Should we really run the wq here? close_file() and
+   * close_directory() runs wq's so I assume that we want them performed
+   * on each item. I had this notion about wq's as something containing
+   * all items in a WC, e.g. we check what needs to be done and then do
+   * it all in one batch. What happens if we have three files done but
+   * three more should have been installed when we get an interrupt? 
+   * Does the editor have some way of marking what has been done and
+   * what has not? E.g. if we run svn_wc_cleanup() on a WC, we're
+   * supposed to finish the remaining work items but the update_editor
+   * may not have recorded all work items, right? Do we check that
+   * revisions match or what? ### */
+  SVN_ERR(svn_wc__wq_run(rtb->db, local_abspath, rtb->cancel_func,
+ rtb->cancel_baton, scratch_pool));
+}
+
+  return SVN_NO_ERROR;
+}
+
 /* An svn_delta_editor_t function. */
 static svn_error_t *
 close_edit(void *edit_baton,
apr_pool_t *pool)
 {
   struct edit_baton *eb = edit_baton;
+  struct reinstall_target_baton rtb;
 
   /* If there is a target and that target is m

Re: How does the workqueues provide atomic updates, or do they?

[Philip Martin]

Daniel Näslund  writes:

> How are files installed during an update?
> 
> We acquire a write lock
> We crawl the wc
> We tell the repos about our state
> The repo runs an editor
>   open_root(): We set status to _status_incomplete
> open_directory(): We set status t _status_incomplete.
>   close_file(): We run the wq
> close_directory(): We run the wq

close_directory will remove status_incomplete for the directory, see
maybe_bump_dir_info.  At present it's a direct database operation but
it may become part of the wq for the directory.

>   close_edit(): Remove status_incomplete
> release write_lock
>
> What if we get interrupted?
> 
> We have this incoming change:
>   M   A/B/lambda
>   M   A/B/beta
>
> But we only process lambda and get cancelled before we start processing
> beta. Then there's no wq started for beta. How does the wq know that the
> update isn't complete?

The wq doesn't know or care.  All the wq knows is whether there are
outstanding items.

> Or is the status that tells us that the update is
> not complete? E.g. the workqueues provide write atomicity but it's the
> status that tells us if the whole operation has succeded?

The status_incomplete remains on the directory.  It will remain until
the user runs update successfully.

> I think it works like this:
> --
> * If the next operation tries to acquire a write lock it will fail and
>   tell the user to run 'svn cleanup'
> * svn_wc_cleanup() will run all remaining work items in the different
>   workqueues (will be one queue when we have one db).

Yes.  Although note that pool cleanups attempt to run any outstanding
wq so controlled cancel will often run any wq and remove locks, just
leaving the incomplete status.

> * Something detects that the update is incomplete and resumes it *or*
>   something detects that the update is incomplete and reverts what has
>   been done so far.

No.  In future it may change but at present the user needs to invoke
update to finish the operation.

-- 
Philip

How does the workqueues provide atomic updates, or do they?

[Daniel Näslund]

Hi!

Some questions about how the workqueues... work.
Have I got it right?

How are files installed during an update?

We acquire a write lock
We crawl the wc
We tell the repos about our state
The repo runs an editor
  open_root(): We set status to _status_incomplete
open_directory(): We set status t _status_incomplete.
  close_file(): We run the wq
close_directory(): We run the wq
  close_edit(): Remove status_incomplete
release write_lock

What if we get interrupted?

We have this incoming change:
  M   A/B/lambda
  M   A/B/beta

But we only process lambda and get cancelled before we start processing
beta. Then there's no wq started for beta. How does the wq know that the
update isn't complete? Or is the status that tells us that the update is
not complete? E.g. the workqueues provide write atomicity but it's the
status that tells us if the whole operation has succeded?

I think it works like this:
--
* If the next operation tries to acquire a write lock it will fail and
  tell the user to run 'svn cleanup'
* svn_wc_cleanup() will run all remaining work items in the different
  workqueues (will be one queue when we have one db).
* Something detects that the update is incomplete and resumes it *or*
  something detects that the update is incomplete and reverts what has
  been done so far.

I assume that the best thing would have been if all items could have
been placed in one workqueue and then be run but that we don't do that
since we don't want to increase the memory usage or slow down the system
by writing a lot of tempfiles holding the incoming changes.

My problem is that I haven't found the code parts that deals with
status_incomplete. I only see: 
If write locks already held -> run the items left in the workqueues.

Thanks,
Daniel