Re: Global ignores

[Ryan Schmidt]

On Oct 7, 2010, at 15:29, Feldhacker, Chris wrote:

> Where can I find more complete information on global-ignores and the expected 
> format/syntax of the patterns?
> 
> The svnbook just indicates:
> The global-ignores option is a list of whitespace-delimited globs which 
> describe the names of files and directories that Subversion should not 
> display unless they are versioned. 
> The default value is *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

You must be reading an old version of the book; the current version shows "The 
default value is *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo 
*.rej *~ #*# .#* .*.swp .DS_Store ."

http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#id531554


> At first I assumed this just performed wild-card matching, but looking at the 
> default list within the config file that was created on my machine (Windows) 
> I see this:
> 
> global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo
>   *.rej *~ #*# .#* .*.swp .DS_Store
> 
> Based on the presence of the "[0-9]" set, I assume something a bit more than 
> just wild-card matching must be performed but apparently something less than 
> full regular expressions...
> 
> The wikipedia entry for "glob" indicates this is just a generic term that 
> refers to a limited pattern-matching facility, which seems to vary by 
> programming language or shell, and "there is no definite syntax for globs..."
> 
> 
> So, where can I find more complete information on the "glob" syntax that 
> Subversion uses for the global-ignores option, and is it consistent across 
> OSes?

I could not find documentation about the specifics of the glob format in the 
Subversion book, so I dove into the code. In 
subversion/libsvn/subr/svn_string.c I found the funciton 
svn_cstring_match_glob_list which just calls through to APR's apr_fnmatch 
function. And in APR's source file include/apr_fnmatch.h there is a long 
comment describing how it works:


/**
 * Try to match the string to the given pattern, return APR_SUCCESS if
 *match, else return APR_FNM_NOMATCH.  Note that there is no such thing as
 *an illegal pattern.
 *
 * With all flags unset, a pattern is interpreted as such:
 *
 * PATTERN: Backslash followed by any character, including another
 *  backslash.
 * MATCHES: That character exactly.
 * 
 * 
 * PATTERN: ?
 * MATCHES: Any single character.
 * 
 * 
 * 
 * PATTERN: *
 * MATCHES: Any sequence of zero or more characters. (Note that multiple
 *  *s in a row are equivalent to one.)
 * 
 * PATTERN: Any character other than \?*[ or a \ at the end of the pattern
 * MATCHES: That character exactly. (Case sensitive.)
 * 
 * PATTERN: [ followed by a class description followed by ]
 * MATCHES: A single character described by the class description.
 *  (Never matches, if the class description reaches until the
 *  end of the string without a ].) If the first character of
 *  the class description is ^ or !, the sense of the description
 *  is reversed.  The rest of the class description is a list of
 *  single characters or pairs of characters separated by -. Any
 *  of those characters can have a backslash in front of them,
 *  which is ignored; this lets you use the characters ] and -
 *  in the character class, as well as ^ and ! at the
 *  beginning.  The pattern matches a single character if it
 *  is one of the listed characters or falls into one of the
 *  listed ranges (inclusive, case sensitive).  Ranges with
 *  the first character larger than the second are legal but
 *  never match. Edge cases: [] never matches, and [^] and [!]
 *  always match without consuming a character.
 * 
 * Note that these patterns attempt to match the entire string, not
 * just find a substring matching the pattern.
 *
 * @param pattern The pattern to match to
 * @param strings The string we are trying to match
 * @param flags flags to use in the match.  Bitwise OR of:
 * 
 *  APR_FNM_NOESCAPE   Disable backslash escaping
 *  APR_FNM_PATHNAME   Slash must be matched by slash
 *  APR_FNM_PERIOD Period must be matched by period
 *  APR_FNM_CASE_BLIND Compare characters case-insensitively.
 * 
 */


In svn_cstring_match_glob_list, Subversion calls apr_fnmatch with no flags set.

Re: svn Farm

[Nico Kadel-Garcia]

On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
 wrote:
>  Le 06/10/2010 17:06, Siva Kumar a écrit :
>>>
>>> I need to provide svn service to many small groups of students.
>>> I'am looking for a tool that would help industrialize managment of
>>> repositories.
>>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
>>> keys
>>> for svn+ssh access etc ...
>>> Are there such  tools already existing  ?
>>
>> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your
>> bill.
>
> good point !
> I've installed and run it, looks good.
> but now I need to find a way to link my ldap users to svn roles/authz , I
> still can't find how to do that wihout creating csvn local accounts for all
> my users :-( ... !?

Unless you can guarantee that they will not use Linux or UNIX based
clients, don't even consider this. The problem is that the Linux and
UNIX clients, by default, continue to store passwords in clear text.
They whinge about it now before storing it, but it's still an issue.

Is there any reason you use 'svn' access, rather than HTTPS? The
mod_dav_svn module works well, even though I detest the clear text
password problem.

There remains no good GUI or published toolkit for svn+ssh access
configuration. This is one of Subversion's profound deficits, combined
with the password issues with the Linux/UNIX clients.  Various
companies and groups have internal kits, including Sourceforge, but
I've never seen their tools published.

Re: svn / Apache installation question

[David Darj]

 On 2010-10-07 10:10, Cooke, Mark wrote:

Folks,

I use apache to host subversion and all seems to be working.  However, I
happened to read the TortoiseSVN help file this morning and noticed the
following:

4. Copy the file /bin/libdb*.dll and /bin/intl3_svn.dll
from the Subversion installation directory to the
Apache bin directory. [1]

I checked and these files are not in the apache bin directory but
nothing seems broken!  Is this advice incorrect / out-of-date or is
something broken that I have not noticed yet?

Many thanks for any insights,

~ mark c

[1]
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-apac
he.html
 under "Installing Subversion"


I'm not sure but i think this should only be necessary if you doesn't 
have the subversion/bin in your search path.


/David

RE: How to determine high-level SVN actions from low-level Apache logs?

[Shaun Pinney]

> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: Thursday, October 07, 2010 1:53 PM
> 
> On Thu, Oct 7, 2010 at 4:46 PM, Shaun Pinney
>  wrote:
> 
> > I'd like to inspect the Apache log files (e.g. access_log) to determine
> SVN
> > activities such as commit, update, svnsync, etc.  How can I do this?
> 
> The best way to do this is to configure Subversion's high-level
> operational logging.  If you use CollabNet Subversion Edge for your
> server it configures Apache to record these logs automatically and you
> can access them via a web UI.  It also offers daily log rotation and
> automated log cleanup  See:
> http://www.open.collab.net/products/subversion/whatsnew.html
> 
> If you want to configure this feature for your own server it is
> documented in the book:
> 
> http://svnbook.red-
> bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extr
> a.logging

(sorry for the earlier top post...)

Hi Mark,

Thanks for the info - I'll try to get this option added to our server.  Right
now, all I have is access_log.  Is there a way to get the same info from
access_log?

Regards,
Shaun

RE: How to determine high-level SVN actions from low-level Apache logs?

[Shaun Pinney]

Hi Mark,

Thanks for the info - I'll try to get this option added to our server.  Right
now, all I have is access_log.  Is there a way to get the same info from
access_log?

Regards,
Shaun

> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: Thursday, October 07, 2010 1:53 PM
> To: Shaun Pinney
> Cc: users@subversion.apache.org
> Subject: Re: How to determine high-level SVN actions from low-level Apache
> logs?
> 
> On Thu, Oct 7, 2010 at 4:46 PM, Shaun Pinney
>  wrote:
> 
> > I'd like to inspect the Apache log files (e.g. access_log) to determine
> SVN
> > activities such as commit, update, svnsync, etc.  How can I do this?
> 
> The best way to do this is to configure Subversion's high-level
> operational logging.  If you use CollabNet Subversion Edge for your
> server it configures Apache to record these logs automatically and you
> can access them via a web UI.  It also offers daily log rotation and
> automated log cleanup  See:
> http://www.open.collab.net/products/subversion/whatsnew.html
> 
> If you want to configure this feature for your own server it is
> documented in the book:
> 
> http://svnbook.red-
> bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extr
> a.logging
> 
> --
> Thanks
> 
> Mark Phippard
> http://markphip.blogspot.com/

Re: How to determine high-level SVN actions from low-level Apache logs?

[Mark Phippard]

On Thu, Oct 7, 2010 at 4:46 PM, Shaun Pinney
 wrote:

> I'd like to inspect the Apache log files (e.g. access_log) to determine SVN
> activities such as commit, update, svnsync, etc.  How can I do this?

The best way to do this is to configure Subversion's high-level
operational logging.  If you use CollabNet Subversion Edge for your
server it configures Apache to record these logs automatically and you
can access them via a web UI.  It also offers daily log rotation and
automated log cleanup  See:
http://www.open.collab.net/products/subversion/whatsnew.html

If you want to configure this feature for your own server it is
documented in the book:

http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.logging

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

How to determine high-level SVN actions from low-level Apache logs?

[Shaun Pinney]

Hello all,

I'd like to inspect the Apache log files (e.g. access_log) to determine SVN
activities such as commit, update, svnsync, etc.  How can I do this?

Thanks,
Shaun

Global ignores

[Feldhacker, Chris]

Where can I find more complete information on global-ignores and the expected 
format/syntax of the patterns?

The svnbook just indicates:
The global-ignores option is a list of whitespace-delimited globs which 
describe the names of files and directories that Subversion should not display 
unless they are versioned. 
The default value is *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

At first I assumed this just performed wild-card matching, but looking at the 
default list within the config file that was created on my machine (Windows) I 
see this:

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo
   *.rej *~ #*# .#* .*.swp .DS_Store

Based on the presence of the "[0-9]" set, I assume something a bit more than 
just wild-card matching must be performed but apparently something less than 
full regular expressions...

The wikipedia entry for "glob" indicates this is just a generic term that 
refers to a limited pattern-matching facility, which seems to vary by 
programming language or shell, and "there is no definite syntax for globs..."


So, where can I find more complete information on the "glob" syntax that 
Subversion uses for the global-ignores option, and is it consistent across OSes?
Thanks!



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

Re: Checked Subversions code with cppcheck

[Hyrum K. Wright]

On Thu, Oct 7, 2010 at 3:06 PM, Itamar O  wrote:
> On Thu, Oct 7, 2010 at 5:04 PM, Philipp Kloke  wrote:
>>
>> ?I am not sure if I am answering correctly (because I usually do not use
>> mailing lists, I just selected the "Answer to all" button of my mail
>> program), but I hope so.
>>
>> I now checked the code again, but with a newer version of cppcheck. The
>> results are in the attachement.
>>
>> If you would like to try to check the code by yourself, see
>> https://sourceforge.net/projects/cppcheck/ (the tool is very easy to use)
>>
>
> I wonder - it seems that Subversion is covered by static-analysis from
> scan.coverity (http://scan.coverity.com/rungAll.html),
> which is a powerful commercial analysis tool (not affiliated), but the
> cppcheck report posted here has stuff that are surely detected by
> coverity...
> Are the dev's really using the reports from scan.coverity?

It's been a while since I've looked at those stats.  The last time I
did, there was something wrong with the scanner which made it only
check a small subset of the code.  Contacting Coverity didn't get me
very far in solving the problem. :/

Trying just now, I can't even log into the system: the login link is
broken for the Subversion project.  I've emailed the admins, and
hopefully it'll get fixed.  Thanks for the reminder.

-Hyrum

Re: Checked Subversions code with cppcheck

[Itamar O]

On Thu, Oct 7, 2010 at 5:04 PM, Philipp Kloke  wrote:

> ?I am not sure if I am answering correctly (because I usually do not use
> mailing lists, I just selected the "Answer to all" button of my mail
> program), but I hope so.


> I now checked the code again, but with a newer version of cppcheck. The
> results are in the attachement.
>
> If you would like to try to check the code by yourself, see
> https://sourceforge.net/projects/cppcheck/ (the tool is very easy to use)
>
>
I wonder - it seems that Subversion is covered by static-analysis from
scan.coverity (http://scan.coverity.com/rungAll.html),
which is a powerful commercial analysis tool (not affiliated), but the
cppcheck report posted here has stuff that are surely detected by
coverity...
Are the dev's really using the reports from scan.coverity?

Re: svn / Apache installation question

[Itamar O]

On Thu, Oct 7, 2010 at 10:10 AM, Cooke, Mark  wrote:

> Folks,
>
> I use apache to host subversion and all seems to be working.  However, I
> happened to read the TortoiseSVN help file this morning and noticed the
> following:
>
> 4. Copy the file /bin/libdb*.dll and /bin/intl3_svn.dll
>   from the Subversion installation directory to the
>   Apache bin directory. [1]
>
> I checked and these files are not in the apache bin directory but
> nothing seems broken!  Is this advice incorrect / out-of-date or is
> something broken that I have not noticed yet?
>
> Many thanks for any insights,
>
> ~ mark c
>
> [1]
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-apac
> he.html
>under "Installing Subversion"
>

I think that if the Subversion/bin directory is in your PATH environment
variable,
you can skip the copy, since the DLLs will be found in svn/bin when it is
needed by Apache.

Re: Why doesn't 'svnadmin create' creates tags, branches, trunk?

[Tech Geek]

I  just noticed that the CollabNet's Subversion Edge has this feature when
you create the repository from the web browser interface.

I guess at least I am not the only one (perhaps) who thought about this.

RE: svn Farm

[Bob Archer]

>   Le 06/10/2010 17:06, Siva Kumar a écrit :
> >> I need to provide svn service to many small groups of students.
> >> I'am looking for a tool that would help industrialize managment
> of
> >> repositories.
> >> I don't want to issue hundreds of "svn create", "vi authz" ,
> edit ssh keys
> >> for svn+ssh access etc ...
> >> Are there such  tools already existing  ?
> > Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might
> fit your bill.
> good point !
> I've installed and run it, looks good.
> but now I need to find a way to link my ldap users to svn
> roles/authz ,
> I still can't find how to do that wihout creating csvn local
> accounts
> for all my users :-( ... !?

Oh man, I thought edge did that for you and provided a web UI to set it up. 
Which is why I was considering moving to it when 1.7 came out. Not so?

BOb

Re: svn Farm

[jehan procaccia]

 Le 06/10/2010 17:06, Siva Kumar a écrit :

I need to provide svn service to many small groups of students.
I'am looking for a tool that would help industrialize managment of
repositories.
I don't want to issue hundreds of "svn create", "vi authz" , edit ssh keys
for svn+ssh access etc ...
Are there such  tools already existing  ?

Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill.

good point !
I've installed and run it, looks good.
but now I need to find a way to link my ldap users to svn roles/authz , 
I still can't find how to do that wihout creating csvn local accounts 
for all my users :-( ... !?

RE: Why doesn't 'svnadmin create' creates tags, branches, trunk?

[Bob Archer]

> > From: Tech Geek [mailto:techgeek12...@gmail.com]
> >
> > So why don't we have (read as a feature) something like this:
> >
> > # svnadmin create --tbt new_repo
> >
> > and a repositroy with following strcuture is created
> (automatically)
> >
> > # ls /var/lib/svn/new_repo
> > branches
> > tags
> > trunk
> 
> I have several repositories of my own, and I support several more,
> for
> various companies that I work for.  None of them have the branches
> & tags at
> the top level of the repo, because the repo actually contains many
> separate
> independent projects.  You should stick your branches & tags dir at
> whatever
> levels of the tree you'd be interested in branching & tagging.
> 
> If you did the -tbt switch, it's just a lazy way to eliminate a
> single "svn
> mkdir" after the "svnadmin create."  Not really worth while, imho.
> If you
> can remember the "-tbt" then you can remember the "svn mkdir."

Create a template repository with the folders you want in it. Then dump it. 
Save that file somewhere. 

After you create a repo you can do an svnadmin load --ignore-uuid < 
templatedumpfile 

(so you retain the unique uuid in the newly created repo).

You can even create a batch/command for this to do it with one command.

BOb

Re: Howto Disable Localistation?

[Nico Kadel-Garcia]

It works because the included svn does not get expanded. But it still
looks confusingly recursive: it's an unfortunate and confusing coding
style, easily avoided by fully qualifying the target of the svn
command.

2010/10/7 Ulrich Eckhardt :
> On Thursday 07 October 2010, Nico Kadel-Garcia wrote:
>> On Wed, Oct 6, 2010 at 10:46 AM, Tony Sweeney  wrote:
>> > alias svn='LANG=en_US svn'
>>
>> You've just written a recursive alias.
>
> No.
>
> Uli
>
> --
> ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
> FAQ: http://subversion.apache.org/faq.html
> Docs: http://svnbook.red-bean.com/
>
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
> **
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **
>           Visit our website at 
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
> sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
> weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
> verantwortlich.
> **
>
>

Re: Checked Subversions code with cppcheck

[Philipp Kloke]

?I am not sure if I am answering correctly (because I usually do not use 
mailing lists, I just selected the "Answer to all" button of my mail 
program), but I hope so.


I now checked the code again, but with a newer version of cppcheck. The 
results are in the attachement.


If you would like to try to check the code by yourself, see 
https://sourceforge.net/projects/cppcheck/ (the tool is very easy to use)



-Ursprüngliche Nachricht- 
From: Hyrum K. Wright

Sent: Thursday, October 07, 2010 2:56 PM
To: Philipp Kloke
Cc: users@subversion.apache.org
Subject: Re: Checked Subversions code with cppcheck

On Mon, Oct 4, 2010 at 9:59 AM, Hyrum K. Wright
 wrote:
On Mon, Oct 4, 2010 at 9:34 AM, Philipp Kloke  
wrote:

?Hi,

I used cppcheck to analyze the source code of Subversion.
Cppcheck claims to have found five errors and some style problems.

Please have a look on the result file in the attachement.


Thanks for the feedback!  I'll look at making some of these changes,
and let you know how it goes.  (In the future, as this is related to
the development of Subversion, feel free to send this type of mail
straight to d...@subversion.apache.org.)


I've incorporated as many fixes as I could, given the drift on trunk.
Could you rerun your tool and report the result back?

Thanks,
-Hyrum 

[subversion\bindings\javahl\native\InputStream.h:45]: (Style) Unused private
function 'InputStream::read'
[subversion\bindings\javahl\native\InputStream.h:46]: (Style) Unused private
function 'InputStream::close'
[subversion\bindings\javahl\native\JNIThreadData.cpp:40]: (Style) Member
variable not initialized in the constructor 'JNIThreadData::m_formatBuffer'
[subversion\bindings\javahl\native\OutputStream.h:44]: (Style) Unused
private function 'OutputStream::write'
[subversion\bindings\javahl\native\OutputStream.h:46]: (Style) Unused
private function 'OutputStream::close'
[subversion\bindings\javahl\native\StatusCallback.cpp:37]: (Style) Member
variable not initialized in the constructor 'StatusCallback::wc_ctx'
[subversion\bindings\javahl\native\SVNClient.cpp:112] ->
[subversion\bindings\javahl\native\SVNClient.h:193]: (Style) The function
'SVNClient::getLastPath' can be const
[subversion\libsvn_auth_kwallet\kwallet.cpp:203]: (Style) Variable 'app' is
assigned a value that is never used
[subversion\libsvn_auth_kwallet\kwallet.cpp:273]: (Style) Variable 'app' is
assigned a value that is never used
[subversion\libsvn_delta\compose_delta.c:46] ->
[subversion\libsvn_delta\compose_delta.c:45]: (Style) Struct
'range_index_node_t' hides typedef with same name
[subversion\libsvn_delta\compose_delta.c:70] ->
[subversion\libsvn_delta\compose_delta.c:69]: (Style) Struct
'range_list_node_t' hides typedef with same name
[subversion\libsvn_delta\compose_delta.c:93] ->
[subversion\libsvn_delta\compose_delta.c:92]: (Style) Union 'alloc_block_t'
hides typedef with same name
[subversion\libsvn_diff\diff.h:62] -> [subversion\libsvn_diff\diff.h:38]:
(Style) Struct 'svn_diff__position_t' hides typedef with same name
[subversion\libsvn_diff\diff.h:69] -> [subversion\libsvn_diff\diff.h:39]:
(Style) Struct 'svn_diff__lcs_t' hides typedef with same name
[subversion\libsvn_diff\diff.c:43]: (Style) Variable 'diff' is not assigned
a value
[subversion\libsvn_diff\lcs.c:43] -> [subversion\libsvn_diff\lcs.c:41]:
(Style) Struct 'svn_diff__snake_t' hides typedef with same name
[subversion\libsvn_diff\token.c:42] -> [subversion\libsvn_diff\diff.h:36]:
(Style) Struct 'svn_diff__node_t' hides typedef with same name
[subversion\libsvn_diff\token.c:52] -> [subversion\libsvn_diff\diff.h:37]:
(Style) Struct 'svn_diff__tree_t' hides typedef with same name
[subversion\libsvn_diff\token.c:144]: (Style) Variable 'start_position' is
not assigned a value
[subversion\libsvn_fs_base\dag.c:64] ->
[subversion\libsvn_fs_base\dag.h:71]: (Style) Struct 'dag_node_t' hides
typedef with same name
[subversion\libsvn_fs_base\bdb\env.c:86] ->
[subversion\libsvn_fs_base\bdb\env.h:47]: (Style) Struct 'bdb_env_t' hides
typedef with same name
[subversion\libsvn_fs_base\bdb\env.c:237]: (Error) Memory leak: error_info
[subversion\libsvn_fs_fs\dag.c:45] -> [subversion\libsvn_fs_fs\dag.h:62]:
(Style) Struct 'dag_node_t' hides typedef with same name
[subversion\libsvn_ra_neon\session.c:454]: (Style) Variable
'http_auth_types' is assigned a value that is never used
[subversion\libsvn_ra_serf\ra_serf.h:138] ->
[subversion\libsvn_ra_serf\ra_serf.h:67]: (Style) Struct
'svn_ra_serf__session_t' hides typedef with same name
[subversion\libsvn_ra_serf\ra_serf.h:1485] ->
[subversion\libsvn_ra_serf\ra_serf.h:68]: (Style) Struct
'svn_ra_serf__auth_protocol_t' hides typedef with same name
[subversion\libsvn_ra_serf\ra_serf.h:596] ->
[subversion\libsvn_ra_serf\ra_serf.h:560]: (Style) Struct
'svn_ra_serf__xml_parser_t' hides typedef with same name
[subversion\libsvn_ra_serf\commit.c:755]: (Error) Uninitialized variable:
prop_name
[subversion\libsvn_ra_serf\merge.c:91] ->
[subversion\libsvn_ra_serf\

Re: Checked Subversions code with cppcheck

[Hyrum K. Wright]

On Mon, Oct 4, 2010 at 9:59 AM, Hyrum K. Wright
 wrote:
> On Mon, Oct 4, 2010 at 9:34 AM, Philipp Kloke  wrote:
>> ?Hi,
>>
>> I used cppcheck to analyze the source code of Subversion.
>> Cppcheck claims to have found five errors and some style problems.
>>
>> Please have a look on the result file in the attachement.
>
> Thanks for the feedback!  I'll look at making some of these changes,
> and let you know how it goes.  (In the future, as this is related to
> the development of Subversion, feel free to send this type of mail
> straight to d...@subversion.apache.org.)

I've incorporated as many fixes as I could, given the drift on trunk.
Could you rerun your tool and report the result back?

Thanks,
-Hyrum

RE: Why doesn't 'svnadmin create' creates tags, branches, trunk?

[Edward Ned Harvey]

> From: Tech Geek [mailto:techgeek12...@gmail.com]
> 
> So why don't we have (read as a feature) something like this:
> 
> # svnadmin create --tbt new_repo
> 
> and a repositroy with following strcuture is created (automatically)
> 
> # ls /var/lib/svn/new_repo
> branches
> tags
> trunk

I have several repositories of my own, and I support several more, for
various companies that I work for.  None of them have the branches & tags at
the top level of the repo, because the repo actually contains many separate
independent projects.  You should stick your branches & tags dir at whatever
levels of the tree you'd be interested in branching & tagging.

If you did the -tbt switch, it's just a lazy way to eliminate a single "svn
mkdir" after the "svnadmin create."  Not really worth while, imho.  If you
can remember the "-tbt" then you can remember the "svn mkdir."

Re: How do I enforce a minimum client version when hosted via httpd

[Stephen Connolly]

That was the trick I was looking for.  Thanks

On 7 October 2010 10:25, Ryan Schmidt  wrote:
> On Oct 7, 2010, at 03:29, Stephen Connolly wrote:
>
>> I remember reading before about a hack/trick that allows you to ensure that 
>> the client is at least mergeinfo aware when the repository is served via 
>> Apache httpd.
>>
>> Google is not being co-operative with my attempts to find the Apache HTTPD 
>> directive that makes this magic happen.
>>
>> IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients 
>> from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall 
>> it being about querying the capabilities of the client and a specific 
>> capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow 
>> blocking clients less than 1.6.13 from connecting ;-)
>
> There is no Apache directive for this; instead, you can write a clause in 
> your start-commit hook script. From the start-commit.tmpl file created for 
> you in every new repository:
>
>
> #   [1] REPOS-PATH   (the path to this repository)
> #   [2] USER         (the authenticated user attempting to commit)
> #   [3] CAPABILITIES (a colon-separated list of capabilities reported
> #                     by the client; see note below)
> #
> # Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
> # clients will typically report at least the "mergeinfo" capability.
> # If there are other capabilities, then the list is colon-separated,
> # e.g.: "mergeinfo:some-other-capability" (the order is undefined).
>
>
> So if the third parameter passed to your start-commit hook script is empty / 
> nonexistent, you know that client is older than 1.5 and you can take some 
> action, such as denying the commit, if that's what you want to do.
>
>

RE: How do I enforce a minimum client version when hosted via httpd

[Jon Foster]

Hi,

Stephen Connolly wrote:
> I remember reading before about a hack/trick that allows you
> to ensure that the client is at least mergeinfo aware when the
> repository is served via Apache httpd.

You can have a start-commit hook.  It can reject commits from clients
that don't have the "mergeinfo" capability.

http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html

> A better trick would allow blocking clients less than 1.6.13 from
connecting ;-)

Subversion sends it's version in the User-Agent string.  You can test
that in your Apache config file.  (But this is probably a bad idea
unless it's an internal SVN server that's locked down by corporate
policy).

http://httpd.apache.org/docs/2.2/howto/access.html#env

Bear in mind that some people may not be using the official Subversion
client.

Kind regards,

Jon


**
This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those 
of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you 
must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: How do I enforce a minimum client version when hosted via httpd

[Ryan Schmidt]

On Oct 7, 2010, at 03:29, Stephen Connolly wrote:

> I remember reading before about a hack/trick that allows you to ensure that 
> the client is at least mergeinfo aware when the repository is served via 
> Apache httpd.
> 
> Google is not being co-operative with my attempts to find the Apache HTTPD 
> directive that makes this magic happen.
> 
> IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients from 
> connecting (though the version limit could be 1.5.0 or 1.5.1 I recall it 
> being about querying the capabilities of the client and a specific capability 
> was only introduced in 1.5.1 or 1.5.2) A better trick would allow blocking 
> clients less than 1.6.13 from connecting ;-)

There is no Apache directive for this; instead, you can write a clause in your 
start-commit hook script. From the start-commit.tmpl file created for you in 
every new repository:


#   [1] REPOS-PATH   (the path to this repository)
#   [2] USER (the authenticated user attempting to commit)
#   [3] CAPABILITIES (a colon-separated list of capabilities reported
# by the client; see note below)
#
# Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
# clients will typically report at least the "mergeinfo" capability.
# If there are other capabilities, then the list is colon-separated,
# e.g.: "mergeinfo:some-other-capability" (the order is undefined).


So if the third parameter passed to your start-commit hook script is empty / 
nonexistent, you know that client is older than 1.5 and you can take some 
action, such as denying the commit, if that's what you want to do.

How do I enforce a minimum client version when hosted via httpd

[Stephen Connolly]

I remember reading before about a hack/trick that allows you to ensure that
the client is at least mergeinfo aware when the repository is served via
Apache httpd.

Google is not being co-operative with my attempts to find the Apache HTTPD
directive that makes this magic happen.

IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients
from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall
it being about querying the capabilities of the client and a specific
capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow
blocking clients less than 1.6.13 from connecting ;-)

Anyway, if somebody could point me to the trick it would be much appreciated

-Stephen

svn / Apache installation question

[Cooke, Mark]

Folks,

I use apache to host subversion and all seems to be working.  However, I
happened to read the TortoiseSVN help file this morning and noticed the
following:

4. Copy the file /bin/libdb*.dll and /bin/intl3_svn.dll
   from the Subversion installation directory to the
   Apache bin directory. [1]

I checked and these files are not in the apache bin directory but
nothing seems broken!  Is this advice incorrect / out-of-date or is
something broken that I have not noticed yet?

Many thanks for any insights,

~ mark c

[1]
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-apac
he.html
under "Installing Subversion"

RE: Subversion 1.6.13 Released

[Cooke, Mark]

> -Original Message-
> From: David Darj [mailto:z...@alagazam.net] 
> Sent: 06 October 2010 19:14
> To: Subversion Development; users; announce
> Subject: Re: Subversion 1.6.13 Released
> 
> 
>   I'm happy to announce my release of Subversion 1.6.13 Win32 
> binaries and installer
> 
> They are available at my website:http://alagazam.net
> and also on SourceForge: http://sourceforge.net/projects/win32svn/
> 

Thanks very much (again) for these!  So far all is working fine.

~ mark c