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: Unable to use filter command properly.

[Feldhacker, Chris]

-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: Tuesday, October 26, 2010 5:16 PM
To: Rajnish Kumar Singh
Cc: users@subversion.apache.org
Subject: Re: Unable to use filter command properly.

Rajnish Kumar Singh wrote on Tue, Oct 26, 2010 at 14:58:46 +0530:
> Hi,
> 
> I am trying to use svndumpfilter command in order to filter one of the folder 
> in the entire repository.
> I just want the dump of the that specific folder.
> 
> So first I created a dump file using the following command:
> svnadmin dump E:\Repositories\OR1234 > E:\OR1234.dump
> 
> I am using the following command for dump filter:
> svndumpfilter include OR1234/Test < E:\OR1234.dump > E:\123.dump
> 
> The dump is created at the given location having name 123.dump.
> 
> But when I am uploading the file to a different repository, it doesn't show 
> any thing.
> I checked the content from the svn server , it shows "there are no item to 
> show in this view"
> I used this command to load the file:
> svnadmin load E:\Repositories\OR123 < E:\123.dump


If "OR1234" is the name of the repository, then I doubt filtering "OR1234/Test" 
is correct -- the name of the repository will not appear inside the repository 
as part of the path.  (Unless you intentionally did do this?)

Try:  "svndumpfilter include Test"


-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: locking down access to a repository

[Feldhacker, Chris]

> But if I remove that line then no one can access the repository
 
Most likely because something else in the configuration isn't quite right...  I 
would suggest setting things up and testing with one LDAP server at a time to 
verify the configuration of each before trying to combine them.
 

  AuthName "Subversion Server"
  AuthType Basic
  AuthBasicAuthoritative On
  AuthBasicProvider ldap
 
  # If ldap checks are used with non-ldap ("valid-user"), set this to off
  AuthzLDAPAuthoritative off
  AuthLDAPURL 
ldaps://gc.company.com:3269/DC=domain,DC=comp,DC=company,DC=com?sAMAccountName?sub?(objectCategory=user)
  AuthLDAPBindDN CN=ADMIN,OU=Users,DC=domain,DC=comp,DC=company,DC=com
  AuthLDAPBindPassword pa$$w0rd



 DAV svn
 SVNPath /Repositories/bu/repo1
 SVNPathAuthz off
 #1 The following users/groups will have read-write permission
 Require ldap-group 
CN=REPO1_USERS,OU=Groups,DC=domain,DC=comp,DC=company,DC=com
 Require ldap-group CN=Admins,OU=Groups,DC=domain,DC=comp,DC=company,DC=com
 Require ldap-user someid
 
 
 #2 For any read-only operation, allow these additional users/groups
Require valid-user
 

 

I know this works. After the "#1" line, add "Require" directives for all the 
groups/users that should read-write access.  After the "#2" line, add any 
"Require" directives for any groups/users that should also have read-only 
access.  In this example, "Require valid-user" is used to mean that any 
authenticated user has read-only access to the repository.
The first Location block must come first; repeat the second Location block as 
many times as necessary for each repository.
 



From: Patricia A Moss [mailto:pmo...@csc.com] 
Sent: Tuesday, November 09, 2010 9:42 AM
To: kmra...@rockwellcollins.com
Cc: users@subversion.apache.org
Subject: Re: locking down access to a repository



>I don't think you want the "Require valid-user" line, since by default it uses 
>ANY of the Require lines as matches.  (And in your case valid-user matches all 
>users so it doesn't care you are also specifying a group and an user.) 

But if I remove that line then no one can access the repository. 


PATI MOSS
System Engineer Sr. Professional
CSC





From:   kmra...@rockwellcollins.com 
To: Patricia A Moss/USA/c...@csc 
Cc: users@subversion.apache.org 
Date:   11/09/2010 10:38 AM 
Subject:Re: locking down access to a repository






Stefan Sperling  wrote on 11/09/2010 08:34:37 AM:
> > I've configured my ldap aliases as follows:
> > 
> > AuthLDAPBindDN FCGNET\svnuser
> > AuthLDAPBindPassword x
> > AuthLDAPURL 
> > ldap://xx.fcg.com:3268/DC=fcg,DC=com?samAccountName?sub?
> > (objectCategory=person)
> > 
> > 
> > AuthLDAPBindDN "CN=fcgvuser,OU=Service 
> > Accounts,OU=Users,OU=Production,DC
> > =vdc,DC=csc,DC=com"
> > AuthLDAPBindPassword xxx
> > AuthLDAPURL ldap://x.vdc.csc.com:3268/DC=vdc,DC=csc,DC=com?sa
> > mAccountName?sub?(objectCategory=person)
> > 
> > 
> > Then in each, specific repositorry configuration file, I have the 
> > following:
> > 
> > dav svn
> > SVNPath /disk01/home/FDCertifications
> > AuthType Basic
> > AuthBasicProvider ldap-FCGNET ldap-VIET
> > AuthzLDAPAuthoritative off
> > AuthName "CSC Subversion Repository"
> > Require valid-user
> > Require ldap-group CN=PRJ 
> > FDCertifications,OU=Europe,OU=Groups,DC=fcg,DC=com
> > Require ldap-user pmoss
> > 

I don't think you want the "Require valid-user" line, since by default it uses 
ANY of the Require lines as matches.  (And in your case valid-user matches all 
users so it doesn't care you are also specifying a group and an user.) 

Kevin R. 




-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 underst

RE: History of a fixed path across all objects

[Feldhacker, Chris]

I think you want the "--ignore-ancestry" option:

http://svnbook.red-bean.com/nightly/en/svn.ref.svn.html#svn.ref.svn.sw




-Original Message-
From: Klaus Ganser [mailto:kgan...@gmail.com] 
Sent: Wednesday, November 10, 2010 1:37 PM
To: David Weintraub
Cc: users@subversion.apache.org
Subject: Re: History of a fixed path across all objects

On Wed, Nov 10, 2010 at 11:32 AM, David Weintraub  wrote:

> You want the entire history of a file called "bar.java" in the path 
> /foo/bar/barfoo from revision #1 to the current revision -- even 
> though it isn't the same bar.java at that location?
>
> Is this correct?

Yes, that is correct.


-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: History of a fixed path across all objects

[Feldhacker, Chris]

-Original Message-
From: Klaus Ganser [mailto:kgan...@gmail.com] 
Sent: Wednesday, November 10, 2010 2:43 PM
To: Feldhacker, Chris
Cc: users@subversion.apache.org
Subject: Re: History of a fixed path across all objects

>> On Wed, Nov 10, 2010 at 12:19 PM, Feldhacker, Chris 
>>  wrote:
>> I think you want the "--ignore-ancestry" option:

> svn log does not support that option.


Ah, my bad.  The "ignore ancestry" option can be used when merging to handle 
delete-recreate scenarios (it treats the resources as the same), but SVN is not 
(yet!?) smart enough to be able to use the "ignore ancestry" option when 
viewing the log...

Good question.  Sounds like a good feature request...


-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: SVN group authentication to AD

[Feldhacker, Chris]

> dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and 
> IT-InfrastructureTeam-SystemAdministrator-R is a member of 
> SVN-Puppet-ReadWrite-P AD group
 

Nested AD groups aren't supported -- not many products do.  Typically, support 
for nested AD groups requires that the client application use the native AD 
APIs rather than generic LDAP APIs.  





From: Dale Bohl [mailto:db...@masoncompaniesinc.com] 
Sent: Monday, November 15, 2010 7:40 AM
To: users@subversion.apache.org
Subject: SVN group authentication to AD



Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and authorization

but yet AD Role groups work just fine.

 

subversion.conf config for "puppet" repository



#puppet repo===



   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName "Subversion Authentication to AD"

 

   # Limit R/W access to certain role groups

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   

 

   # Limit R/O access to certain role group

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   



 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown commented

out, authentication doesn't work and when that happens I'm seeing the following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in 
required group(s).

 

So, even though the following User > Role > Permissions > Resource association

exists, the group with '-P' in it above won't allow dpb to authenticate for 
repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of 
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com  
(715)-720-4382

 



-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: SVN group authentication to AD

[Feldhacker, Chris]

Sorry -- disregard my post.  

I overlooked the "Auth_PAMEnabled" line and assumed you were using the standard 
LDAP authz Apache modules, which don't support nested groups.

However, while you're waiting for someone with more PAM knowledge to reply, I 
would wonder if perhaps the cause could be similar -- I would check the 
documentation for the specific PAM module you are using and verify nested 
groups are supported...



-Original Message-----
From: Feldhacker, Chris [mailto:feldhacker.ch...@principal.com] 
Sent: Monday, November 15, 2010 7:50 AM
To: Dale Bohl
Cc: users@subversion.apache.org
Subject: RE: SVN group authentication to AD

> dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and 
> IT-InfrastructureTeam-SystemAdministrator-R is a member of 
> SVN-Puppet-ReadWrite-P AD group
 

Nested AD groups aren't supported -- not many products do.  Typically, support 
for nested AD groups requires that the client application use the native AD 
APIs rather than generic LDAP APIs.  





From: Dale Bohl [mailto:db...@masoncompaniesinc.com]
Sent: Monday, November 15, 2010 7:40 AM
To: users@subversion.apache.org
Subject: SVN group authentication to AD



Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and authorization

but yet AD Role groups work just fine.

 

subversion.conf config for "puppet" repository



#puppet repo===



   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName "Subversion Authentication to AD"

 

   # Limit R/W access to certain role groups

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   

 

   # Limit R/O access to certain role group

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   



 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown commented

out, authentication doesn't work and when that happens I'm seeing the following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in 
required group(s).

 

So, even though the following User > Role > Permissions > Resource association

exists, the group with '-P' in it above won't allow dpb to authenticate for 
repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of 
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com <mailto:db...@masoncompaniesinc.com> 
(715)-720-4382

 



-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: Subversion Apache2.2 LDAPS authentication failed

[Feldhacker, Chris]

-Original Message-
From: 金健康 [mailto:jinjiankang1...@gmail.com] 
Sent: Friday, February 25, 2011 12:53 AM
To: users@subversion.apache.org
Subject: Subversion Apache2.2 LDAPS authentication failed

Hi,

OS: Redhat Linux
Subversion: 1.5.0
Apache: 2.2.17
OpenLDAP: 2.3.27

httpd.conf:
...
LDAPSharedCacheSize 20
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600


DAV svn
SVNParentPath /home/svnroot/repository
AuthzSVNAccessFile /home/svnroot/repository/svn_access_file
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL 
"ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectClass=*)"
SS
L
AuthName "Subversion.resository"
Require valid-user

...

Apache error_log:

[Thu Feb 24 16:48:00 2011] [debug] mod_authnz_ldap.c(403): [client 10.1.85.181] 
[25242] auth_ldap a
uthenticate: using URL
ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectCl
ass=*)
[Thu Feb 24 16:48:00 2011] [info] [client 10.1.85.181] [25242] auth_ldap 
authenticate: user jinjian kang authentication failed; URI /svn [LDAP: 
ldap_simple_bind_s() failed][Can't contact LDAP server]

ping master.ldap.ebupt.com is OK.

My FTP LDAPS authentication is OK as below:
server:master.ldap.ebupt.com
port:636 Enable
SSL:checked
Base DN:ou=staff,dc=ebupt,dc=com
anonymous bind:checked
Search Filter:(objectClass=*)
User DN attribute:uid
Search scope:subtree

Thanks.
Jin Jiankang



I don't see any "LDAPTrustedGlobalCert" entries that tell Apache how to verify 
the server certificate...  Have you defined any in the config file?
http://httpd.apache.org/docs/2.2/mod/mod_ldap.html

Otherwise, you could also try adding this directive to see if it has any affect:
LDAPVerifyServerCert Off

Other than checking to verify the host name matches what's in the certificate, 
and making sure the CAs are setup, you could also check out this message:
http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=395193

FWIW!







-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: Understanding merging

[Feldhacker, Chris]

 
-Original Message-
From: Steve Cohen [mailto:stevec...@comcast.net] 
Sent: Tuesday, March 08, 2011 12:20 PM
To: users@subversion.apache.org
Subject: Understanding merging

> I work with a very senior colleague who has never always resisted version 
> control and would much rather do without it, but he is forced to go along and 
> I am the whipping boy whenever something goes wrong.
> He poses a general but simple question that I find myself unable to give a 
> simple answer to.  I am rephrasing it slightly but it bothers me that I don't 
> know the simple answer.  If I found myself in this situation I would tweak 
> until it was as desired, but my persnickety colleague is not satisfied with 
> such answers and for once, I don't blame him.
> Given two branches off a trunk that were taken at different times, if the 
> first is merged back to the trunk and then the second, how may the second be 
> merged back into the trunk so as not to override changes from the first 
> merge, assuming that both change sets are desired to be in the trunk at the 
> end?



Do the branches receive updates from trunk or not?
If the answer is yes, then before merging a branch back to trunk, one final 
update from trunk to the branch must be performed.  The branch is now 
up-to-date with trunk, and (ideally) the changes on the branch should be 
retested to make sure everything works.  When ready, the branch is merged using 
the "reintegrate" option back to the trunk.  Using "reintegrate", the 
differences between the branch and the trunk are computed and the changes 
applied to the trunk.

If the answer is no, then when the changes on the branch are ready to be merged 
back to the trunk the "reintegrate" option must NOT be used.  Without 
"reintegrate", the changes made on the branch are collected and effectively 
"replayed" on the trunk, which will have the desired result regardless of 
whether or not additional changes to trunk have already been made.

So, a specific decision must be made as to whether or not "reintegrate" should 
be used, and the correct answer depends on whether or not the branch receives 
updates from trunk during its life.  

As long as the correct choice is made each time a branch is merged, then no 
changes will be undone or "overridden".

(It would be really nice if Subversion could detect that a branch has received 
updates from the origin and follow the best practice of "do the right thing by 
default", but...it is what it is!)






-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: How to control changes to path-based auth file?

[Feldhacker, Chris]

In a nutshell:  http://www.svn-access-manager.org/

Basically, store all your settings in a database and generate the config files; 
just use a simple web front-end to edit the database and control/log changes 
that way.  The svn access manager provides a good starting point, modify and 
tweak as needed.




-Original Message-
From: Cooke, Mark [mailto:mark.co...@siemens.com] 
Sent: Monday, May 09, 2011 11:19 AM
To: users@subversion.apache.org
Subject: How to control changes to path-based auth file?

Dear list,

I was wondering how other (probably corporate?) svn users control and log 
changes to your path-based auth file (and other svn web settings)?

I was thinking that I could use svn and the auto-website-update FAQ
(http://subversion.apache.org/faq.html#website-auto-update) to control access 
by allowing named users access to the relevant repo...  However this seems a 
little clunky and 'overkill' for what we have.

We also use `Trac` and there are a couple of trac-hacks:
 * http://trac-hacks.org/wiki/SvnAuthzAdminPlugin
 * http://trac-hacks.org/wiki/TracSvnAuthzPlugin
...that enable editing of the path-based-auth file through Trac but neither 
include any versioning (for auditing purposes).

Can anyone recommend any other routes?

For information, we use Trac and subversion, served from windows server via 
apache...

Many thanks,

~ mark c


-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: copying subdirectories in subversion 1.7

[Feldhacker, Chris]

>  I wonder if people will expect a script named "detach" to copy or do they 
> think it will move?

More like "extract" or "promote" -- promoting a child folder to become a 
full-fledged, independent working copy...

"liberate"?  Kinda like that...  :-)


-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: LDAP Group Configuration in AuthzSVNAccessFile

[Feldhacker, Chris]

If you're willing to give up fine-grained, path-based authorization then you 
can use LDAP groups to secure access to entire repositories at the top-level.  
Just define a "Location" for each respository and use Apache's LDAP integration 
capabilities to secure each location with one or more LDAP groups.
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

Works fine for us!

The example below gives all authenticated users access to the "Publications" 
repository, but only members of the AD group "SOMEAdingGroup" have read-write 
access.


  AuthName "Subversion Server"
  AuthType Basic
  AuthBasicAuthoritative On
  AuthBasicProvider ldap

  # If ldap checks are to be used with non-ldap checks (like "valid-user"), set 
this to off
  AuthzLDAPAuthoritative off
  AuthLDAPURL 
ldaps://ad.company.com:3269/DC=ad,DC=company,DC=com?sAMAccountName?sub?(objectCategory=user)
  AuthLDAPBindDN CN=SOMEADMIN,OU=Users,DC=ad,DC=company,DC=com
  AuthLDAPBindPassword secret



  DAV svn
  SVNPath \Repositories\Publications
  SVNPathAuthz off

  # The following users/groups will have read-write permission
  Require ldap-group CN=SOMEAdminGroup,OU=Groups,DC=ad,DC=company,DC=com

  
# For any read-only operation, allow these additional users/groups
Require valid-user
  

  

-Original Message-
From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] 
Sent: Thursday, April 01, 2010 10:02 AM
To: 'Lee Kaufman'
Cc: users@subversion.apache.org
Subject: RE: LDAP Group Configuration in AuthzSVNAccessFile

> Thank you for your help but I think you may have misunderstood my 
> question.
> In your previous email where you showed the content of your 
> AuthzSVNAccessFile file as.  What I am looking for is to be able to is 
> where you say
>
> [groups]
> developers = Giulio Troccoli, Harpal Panesar
>
> I want to be able to say
> developers = CN=*,OU=Security Groups,... A group I have defined in 
> LDAP.
>
> The groups and user permissions are already defined for other 
> applications and services and I do not want to have to manage them in 
> LDAP and SVN.  Know of any way of doing that?
>

Yes, sorry, I misunderstood you. I thought you meant "group" as in "a group in 
the access file", like the developers group I have.

No, I don't think it's possible. The only way I can think of is the script that 
Stefan already suggested.

Giulio


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447






-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: What does "Repository moved temporarily " mean?

[Feldhacker, Chris]

> "svn: Repository moved temporarily to 'https://[snip] please relocate"

Are you going through a proxy server?
What happens if you execute the exact same command twice in a row?


We go through a proxy, and when I want to download the latest copy of Subclipse 
I issue the command:
"svn export --username guest 
http://subclipse.tigris.org/svn/subclipse/trunk/www/update_1.6.x";
...and I also get the same "svn: Repository moved temporarily..." response.

But, if I issue the exact same command again, it works fine. (And will continue 
to work until I reboot.)
My guess would be that the proxy is sending back a response that the Subversion 
client doesn't quite know how to handle correctly...




-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: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

[Feldhacker, Chris]

Any "rough" documentation available, particularly in terms of security or 
access control?

Remote "dump" makes sense -- and I assume everything being dumped is subject to 
the authorization/access control restrictions that have been put into place on 
the server, yes?  (A particular path or file won't be included in the dump if 
the user doesn't have permission to access it, right?)

Remote "load" seems scary -- How can I prevent my users from being able to use 
this command?  Is the original author of the dumped revision preserved, or is 
the author set to the user doing the load?  Can users do anything else bad, 
like changing repo UUID?

Right now svnadmin is great because performing admin functions is controlled by 
requiring actual access to the box.  If admin functions are now going to be 
available remotely, then I would want to make sure there was a way to make sure 
these functions could only be performed by authorized users...



-Original Message-
From: Ramkumar Ramachandra [mailto:artag...@gmail.com] 
Sent: Wednesday, August 18, 2010 1:51 PM
To: Subversion Users Mailing List
Cc: Daniel Shahaf; Bert Huijben; Stefan Sperling
Subject: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

Hi,

There's now a new tool located in subversion/svnrdump. We have developed it 
over the last few weeks, and we feel that it is mature enough to announce. 
Although it has not been tested extensively, we would like to encourage you to 
try it out and give us feedback so we can improve it.

So what is svnrdump? It is a tool to produce a dumpfile from a remote 
repository without having to mirror the whole thing on the hard disk, as well 
as load a dumpfile into a remote repository. Although it's fundamentally 
different from the `svnadmin` tool on the inside, it can be thought of as 
providing a remote `svnadmin dump | load` functionality. It currently only 
works with dumpfile v3, and we intend to keep it that way.

svnrdump is meant to be a lightweight high-performance tool that is intended to 
be useful to both server admins and developers of other versioning systems 
looking to import/ export revision history from Subversion. The motivation for 
the project actually arises from my recent GSoC project, git-remote-svn; the 
Git developers are writing in support for seamless interoperability with 
Subversion.

Anyway, we hope you find the tool useful; do test it on your own repositories 
and file issues/ feature requests.

-- Ram


-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: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

[Feldhacker, Chris]

Ramkumar:
> Again, I expect that access control/ security is automatically taken care 
> of in the RA layer. `svnrdump load` is just like a user making some changes 
> and committing them one by one except the author and timestamp in the 
> dumpfile are preserved. Why would you want to block this?

A client performing a regular commit cannot currently spoof the author and 
timestamp, or can they?










-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.