Re: SVN 1.7.2 crashes immediately on start in APR xlate/xlate.c

[Philip Martin]

Sebastian Magda  writes:

> Built and installed the latest stable version
> subversion-1.7.2.tar.gz
> Crashes immediately on start:
>
> : svn
> Segmentation fault (core dumped)

> : gcc -v
> Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk
> --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-11)

That's a very old gcc, it's probably this problem:

http://subversion.apache.org/docs/release-notes/1.7.html#rhel-2-issue

-- 
Philip

Re: The content was displayed when i executed the command "update"

[Andy Levy]

>
> In file
>  'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\update_editor.c'
>  line 1582: assertion failed (action == svn_wc_conflict_action_edit ||
> action
>  == svn_wc_conflict_action_delete || action ==
> svn_wc_conflict_action_replace)

Please update to the current release of TortoiseSVN and/or Subversion
to see if this was resolved already. A number of bug fixes have been
made.

Can't check out http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller with serf

[Attila Nagy]

Hi,

I'm using subversion 1.7.2 with serf 1.0.0 on FreeBSD to check out 
http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller, but it 
fails at:

bootvm# svn co http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller
Acontroller/atmegadci_atmelarm.c
Acontroller/at91dci.c
Acontroller/xhcireg.h
Acontroller/musb_otg_atmelarm.c
Acontroller/at91dci.h
Acontroller/ehci_pci.c
Acontroller/ohci_atmelarm.c
Acontroller/uss820dci_atmelarm.c
Acontroller/ehci.c
Acontroller/ohci_s3c24x0.c
Acontroller/ehci_mv.c
Acontroller/ohci_pci.c
Acontroller/atmegadci.c
Acontroller/ehcireg.h
Acontroller/ehci.h
Acontroller/musb_otg.c
Acontroller/at91dci_atmelarm.c
Acontroller/uhci_pci.c
Acontroller/avr32dci.c
Acontroller/avr32dci.h
Acontroller/ohci.c
Acontroller/atmegadci.h
Acontroller/musb_otg.h
Acontroller/uss820dci.c
Acontroller/ohcireg.h
Acontroller/xhci_pci.c
Acontroller/ohci.h
Acontroller/xhci.c
Acontroller/usb_controller.c
Acontroller/xhci.h
Acontroller/uhci.c
Acontroller/uss820dci.h
Acontroller/uhcireg.h
Acontroller/ehci_ixp4xx.c
Acontroller/uhci.h
svn: E175009: XML parsing failed: (207 Multi-Status)

With neon, the checkout succeeds.

Re: Can't check out http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller with serf

[Philip Martin]

Attila Nagy  writes:

> I'm using subversion 1.7.2 with serf 1.0.0 on FreeBSD to check out
> http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller, but it
> fails at:
> bootvm# svn co http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller
> Acontroller/atmegadci_atmelarm.c
[...]
> Acontroller/uhci.h
> svn: E175009: XML parsing failed: (207 Multi-Status)
>
> With neon, the checkout succeeds.

I can reproduce that.  The server is sending:

HTTP/1.1 207 Multi-Status\r
Date: Mon, 30 Jan 2012 14:17:15 GMT\r
Server: Apache/2.2.19 (FreeBSD) mod_ssl/2.2.19 OpenSSL/0.9.8q DAV/2 SVN/1.6.17\r
Vary: Label\r
Content-Length: 1396\r
Content-Type: text/xml; charset="utf-8"\r
\r


http://subversion.tigris.org/xmlns/svn/"; 
xmlns:C="http://subversion.tigris.org/xmlns/custom/"; 
xmlns:V="http://subversion.tigris.org/xmlns/dav/"; xmlns:lp1="DAV:" 
xmlns:lp3="http://subversion.tigris.org/xmlns/dav/"; 
xmlns:lp2="http://apache.org/dav/props/";>
/base/!svn/bln/230302


xhci.h
xhci.c
xhci.h

0
text/plain
"230302//stable/9/sys/dev/usb/controller"
2012-01-18T07:57:17.471381Z
Wed, 18 Jan 2012 07:57:17 GMT
230302
hselasky
###error###
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f








HTTP/1.1 200 OK




and I'd guess that the ###error### in the checksum is the problem.

-- 
Philip

Re: Can't check out http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller with serf

[Daniel Shahaf]

Attila Nagy wrote on Mon, Jan 30, 2012 at 14:55:36 +0100:
> Hi,
> 
> I'm using subversion 1.7.2 with serf 1.0.0 on FreeBSD to check out
> http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller, but it
> fails at:
> bootvm# svn co http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller
...
> Acontroller/uhci.h
> svn: E175009: XML parsing failed: (207 Multi-Status)
> 
> With neon, the checkout succeeds.

The controller/ directory has these properties set:

% svn pl -v wc-neon
Properties on 'wc-neon':
  svn:eol-style=native
xhci.h
  svn:keywords=FreeBSD=%H
xhci.c
  svn:mime-type=text/plain
xhci.h

Now, a the characters [/=%] are invalid in a Subversion property names:

% $svn ps / v iota
subversion/svn/propset-cmd.c:67: (apr_err=195011)
svn: E195011: '/' is not a valid Subversion property name
zsh: exit 1 $SVN ps / v iota
% $svn ps = v iota
subversion/svn/propset-cmd.c:67: (apr_err=195011)
svn: E195011: '=' is not a valid Subversion property name
zsh: exit 1 $SVN ps = v iota
% $svn ps % v iota
subversion/svn/propset-cmd.c:67: (apr_err=195011)
svn: E195011: '%' is not a valid Subversion property name
zsh: exit 1 $SVN ps % v iota

In the meantime, get the repository administrators to remove properties
that have invalid names (in the sense of svn_prop_name_is_valid()).  For
the longer term fix, a related issue --- #4106 --- was filed earlier
today (so it's too early to tell when it might be fixed):
http://subversion.tigris.org/issues/show_bug.cgi?id=4106

Daniel
(there's ongoing IRC discussion)

Apache directives to avoid DDOS

[Nouha Terzi]

Hi,

As suggested here:
https://community.qualys.com/blogs/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks
Modifying those directives can protect against slow HTTP attacks and make
the attacks more difficult to execute:

- LimitRequestFields
- LimitRequestFieldSize
- LimitRequestBody
- LimitRequestLine
- LimitXMLRequestBody
- TimeOut
- KeepAliveTimeOut
- ListenBackLog’s
- MaxRequestWorkers
- AcceptFilter

Does someone already configured a svn apache server to handle slow http
attacks?
Is there any known impact of theses apache directives?

Thank you in advance.
-- 
Nouha

What happens when revision numbers are not chronological?

[Alexander Shenkin]

Hi Folks,

I've used an import script to import two bunches of files in the same
repository.  This import script sets the commit time of each file
(svn:date property) to the original modified-time of the file.  So, when
I added the second batch of files, the dates associated with the
revision numbers are no longer chronological.  That is, rev 5 might have
an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
for example.

I'm not planning on doing anything overly complex with svn - i probably
won't be branching or merging.  However, I would like to be a little
more educated about the risks that I am running.  Anyone know?

thanks!

Directory Already Added Bug?

[Jon Hardcastle]

Hi,

I have an issue where by i am trying to merge a directory structure from a
into b.

One of the changes in that structure is that a directory that is already
present in b has been deleted and re-added in a.

Hence I am trying to merge in the re-add. The only flagging of this I see
is a tree conflict telling it was already added and the ONLY option is
'Keep the local directory' which is unlikely to be the desired actions
since one went to the trouble of merging a into b perhaps one might want
the 'already added' contents from a? instead of the statusquo of b?

Is this correct?

-- 
--
N: Jon Hardcastle
E: j...@ehardcastle.com
Q: The avalanche has already started. It is too late for the pebbles to
vote.

Re: What happens when revision numbers are not chronological?

[Stefan Sperling]

On Mon, Jan 30, 2012 at 11:06:19AM -0500, Alexander Shenkin wrote:
> Hi Folks,
> 
> I've used an import script to import two bunches of files in the same
> repository.  This import script sets the commit time of each file
> (svn:date property) to the original modified-time of the file.  So, when
> I added the second batch of files, the dates associated with the
> revision numbers are no longer chronological.  That is, rev 5 might have
> an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
> for example.
> 
> I'm not planning on doing anything overly complex with svn - i probably
> won't be branching or merging.  However, I would like to be a little
> more educated about the risks that I am running.  Anyone know?
> 
> thanks!

See the warning at the bottom of this page:
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html#svn.tour.revs.dates

Basically, you are confusing the binary search algorithm that is
invoked when you pass a date argument to the -r option. Other than
that, there is no harm.

Re: Could not read chunk size: connection was closed by server

[Justin Johnson]

On Wed, Nov 23, 2011 at 11:46 AM, Justin Johnson
 wrote:
>>
>>> during a checkout.
>>>
>>>   Could not read chunk size: connection was closed by server
>>>
>>> In the server logs the following errors appear around the same time.
>>>
>>>   Provider encountered an error while streaming a REPORT response.  [500, 
>>> #0]
>>>   A failure occurred while driving the update report editor  [500, #130]
>>>   Error writing base64 data: Software caused connection abort  [500, #130]
>>
>> The server failed to write to the client and the client failed to read
>> from the server.  Looks like a network problem caused the connection to
>> be shut down.  To diagnose it you probably need to capture a network
>> trace of some sort.
>>
>
> What we've seen is that normal behavior is to have numerous TCP Zero
> Window flags occur during a checkout.
>
> http://wiki.wireshark.org/TCP%20ZeroWindow
>
> Occasionally we get the errors above and the Wireshark capture
> indicates the Subversion server eventually just terminates the
> connection.  I can gather more details if it would be helpful, but I
> won't be able to include all of the capture details on his mailing
> list.

For the record, we resolved the chunk size error by reconfiguring
Apache to use the prefork MPM instead of worker.

The base64 errors appear to be unrelated and only show up in log files.

Re: What happens when revision numbers are not chronological?

[Ryan Schmidt]

On Jan 30, 2012, at 10:06, Alexander Shenkin wrote:

> I've used an import script to import two bunches of files in the same
> repository.  This import script sets the commit time of each file
> (svn:date property) to the original modified-time of the file.  So, when
> I added the second batch of files, the dates associated with the
> revision numbers are no longer chronological.  That is, rev 5 might have
> an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
> for example.
> 
> I'm not planning on doing anything overly complex with svn - i probably
> won't be branching or merging.  However, I would like to be a little
> more educated about the risks that I am running.  Anyone know?

You will not be able to use the date syntax to specify revisions. For example:

svn log -r '{2012-01-01}:{2012-01-11}'

This is not guaranteed to return sensible results if your revisions are not in 
ascending chronological order. I'm not sure what it will do, but I wouldn't be 
surprised if it returned revisions outside the requested range, and/or did not 
return the revisions that are in the requested range. If I remember correctly, 
the Subversion repository of the Apache Software Foundation has 
non-chronological revisions, so you could do some tests against their 
repository if you're curious.

But that's the only problem I know of.

Re: What happens when revision numbers are not chronological?

[Alexander Shenkin]

thanks all for your helpful replies.

On 1/30/2012 1:13 PM, Ryan Schmidt wrote:
> On Jan 30, 2012, at 10:06, Alexander Shenkin wrote:
>
>> I've used an import script to import two bunches of files in the same
>> repository.  This import script sets the commit time of each file
>> (svn:date property) to the original modified-time of the file.  So, when
>> I added the second batch of files, the dates associated with the
>> revision numbers are no longer chronological.  That is, rev 5 might have
>> an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
>> for example.
>>
>> I'm not planning on doing anything overly complex with svn - i probably
>> won't be branching or merging.  However, I would like to be a little
>> more educated about the risks that I am running.  Anyone know?
> You will not be able to use the date syntax to specify revisions. For example:
>
> svn log -r '{2012-01-01}:{2012-01-11}'
>
> This is not guaranteed to return sensible results if your revisions are not 
> in ascending chronological order. I'm not sure what it will do, but I 
> wouldn't be surprised if it returned revisions outside the requested range, 
> and/or did not return the revisions that are in the requested range. If I 
> remember correctly, the Subversion repository of the Apache Software 
> Foundation has non-chronological revisions, so you could do some tests 
> against their repository if you're curious.
>
> But that's the only problem I know of.
>
>
>

Limited subdirectory access

[K F]

We have repo ABC with 40+ subdirectories. Current svn security allows 
developers rw permissions and qa read only to ABC. We would like to have a 
subgroup of dev to have access to subdirectory DEF (ABC/DEF). Is there a way of 
doing this, or does the parent directory access take precedent?

Thanks,
Rich

Re: Limited subdirectory access

[Andy Levy]

On Mon, Jan 30, 2012 at 15:39, K F  wrote:
> We have repo ABC with 40+ subdirectories. Current svn security allows 
> developers rw permissions and qa read only to ABC. We would like to have a 
> subgroup of dev to have access to subdirectory DEF (ABC/DEF). Is there a way 
> of doing this, or does the parent directory access take precedent?

The most specific path matches first. Just add a rule for that
subgroup to have access to ABC/DEF and they'll be set.

Re: Limited subdirectory access

[K F]

--- On Mon, 1/30/12, Andy Levy  wrote:

> From: Andy Levy 
> Subject: Re: Limited subdirectory access
> To: "K F" 
> Cc: users@subversion.apache.org
> Date: Monday, January 30, 2012, 8:45 PM
> On Mon, Jan 30, 2012 at 15:39, K F
> 
> wrote:
> > We have repo ABC with 40+ subdirectories. Current svn
> security allows developers rw permissions and qa read only
> to ABC. We would like to have a subgroup of dev to have
> access to subdirectory DEF (ABC/DEF). Is there a way of
> doing this, or does the parent directory access take
> precedent?
> 
> The most specific path matches first. Just add a rule for
> that
> subgroup to have access to ABC/DEF and they'll be set.
> 

OK, then I must be doing something wrong. This is how I have it setup in the 
authz file now:
[/]
@dev = rw
@qa = r

[/ABC/DEF]
@dev1 = rw

Do I need to be more specific?

Re: Limited subdirectory access

[Andy Levy]

On Mon, Jan 30, 2012 at 15:52, K F  wrote:
>
>
> --- On Mon, 1/30/12, Andy Levy  wrote:
>
>> From: Andy Levy 
>> Subject: Re: Limited subdirectory access
>> To: "K F" 
>> Cc: users@subversion.apache.org
>> Date: Monday, January 30, 2012, 8:45 PM
>> On Mon, Jan 30, 2012 at 15:39, K F
>> 
>> wrote:
>> > We have repo ABC with 40+ subdirectories. Current svn
>> security allows developers rw permissions and qa read only
>> to ABC. We would like to have a subgroup of dev to have
>> access to subdirectory DEF (ABC/DEF). Is there a way of
>> doing this, or does the parent directory access take
>> precedent?
>>
>> The most specific path matches first. Just add a rule for
>> that
>> subgroup to have access to ABC/DEF and they'll be set.
>>
>
> OK, then I must be doing something wrong. This is how I have it setup in the 
> authz file now:
> [/]
> @dev = rw
> @qa = r
>
> [/ABC/DEF]
> @dev1 = rw
>
> Do I need to be more specific?
>

What exactly isn't working?

Is dev1 a group, or an individual?

Do you have the case of the path matched exactly? The rules are case-sensitive.

Re: Limited subdirectory access

[K F]

--- On Mon, 1/30/12, Andy Levy  wrote:

> From: Andy Levy 
> Subject: Re: Limited subdirectory access
> To: "K F" 
> Cc: users@subversion.apache.org
> Date: Monday, January 30, 2012, 8:57 PM
> On Mon, Jan 30, 2012 at 15:52, K F
> 
> wrote:
> >
> >
> > --- On Mon, 1/30/12, Andy Levy 
> wrote:
> >
> >> From: Andy Levy 
> >> Subject: Re: Limited subdirectory access
> >> To: "K F" 
> >> Cc: users@subversion.apache.org
> >> Date: Monday, January 30, 2012, 8:45 PM
> >> On Mon, Jan 30, 2012 at 15:39, K F
> >> 
> >> wrote:
> >> > We have repo ABC with 40+ subdirectories.
> Current svn
> >> security allows developers rw permissions and qa
> read only
> >> to ABC. We would like to have a subgroup of dev to
> have
> >> access to subdirectory DEF (ABC/DEF). Is there a
> way of
> >> doing this, or does the parent directory access
> take
> >> precedent?
> >>
> >> The most specific path matches first. Just add a
> rule for
> >> that
> >> subgroup to have access to ABC/DEF and they'll be
> set.
> >>
> >
> > OK, then I must be doing something wrong. This is how I
> have it setup in the authz file now:
> > [/]
> > @dev = rw
> > @qa = r
> >
> > [/ABC/DEF]
> > @dev1 = rw
> >
> > Do I need to be more specific?
> >
> 
> What exactly isn't working?
> 
> Is dev1 a group, or an individual?
> 
> Do you have the case of the path matched exactly? The rules
> are case-sensitive.
> 

I am able to commit with a login that is in the dev group that is not in the 
dev1 group.

The actual path is /svnrepo/ABC/DEF so I tried

[/svnrepo/sandbox/tags]
@dev1 = rw

and that doesn't work either. Based on the example in the file I also tried

[repository:/svnrepo/sandbox/tags]
@dev1 = rw

with no luck. Any ideas as to what I am doing wrong?

Re: Limited subdirectory access

[Stefan Sperling]

On Mon, Jan 30, 2012 at 01:14:53PM -0800, K F wrote:
> --- On Mon, 1/30/12, Andy Levy  wrote:
> > have it setup in the authz file now:
> > > [/]
> > > @dev = rw
> > > @qa = r
> > >
> > > [/ABC/DEF]
> > > @dev1 = rw
> > >
> > > Do I need to be more specific?
> > >
> > 
> > What exactly isn't working?
> > 
> > Is dev1 a group, or an individual?
> > 
> > Do you have the case of the path matched exactly? The rules
> > are case-sensitive.
> > 
> 
> I am able to commit with a login that is in the dev group that is not in the 
> dev1 group.
> 
> The actual path is /svnrepo/ABC/DEF so I tried
> 
> [/svnrepo/sandbox/tags]
> @dev1 = rw
> 
> and that doesn't work either. Based on the example in the file I also tried
> 
> [repository:/svnrepo/sandbox/tags]
> @dev1 = rw
> 
> with no luck. Any ideas as to what I am doing wrong?

You'll need to tighten permissions for the 'dev' group in /ABC/DEF also.
[/]
@dev = rw
@qa = r

[/ABC/DEF]
@dev = r  
@dev1 = rw

See this snippet from
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
  "Of course, permissions are inherited from parent to child directory.
  That means we can specify a subdirectory with a different access policy
  for Sally:
  
  [calc:/branches/calc/bug-142]
  harry = rw
  sally = r
  
  # give sally write access only to the 'testing' subdir
  [calc:/branches/calc/bug-142/testing]
  sally = rw
  
  Now Sally can write to the testing subdirectory of the branch, but can
  still only read other parts. Harry, meanwhile, continues to have
  complete read/write access to the whole branch."

The same applies when restricting access, rather than expanding it.

Re: Limited subdirectory access

[K F]

--- On Mon, 1/30/12, Stefan Sperling  wrote:

> From: Stefan Sperling 
> Subject: Re: Limited subdirectory access
> To: "K F" 
> Cc: "Andy Levy" , users@subversion.apache.org
> Date: Monday, January 30, 2012, 9:32 PM
> On Mon, Jan 30, 2012 at 01:14:53PM
> -0800, K F wrote:
> > --- On Mon, 1/30/12, Andy Levy 
> wrote:
> > > have it setup in the authz file now:
> > > > [/]
> > > > @dev = rw
> > > > @qa = r
> > > >
> > > > [/ABC/DEF]
> > > > @dev1 = rw
> > > >
> > > > Do I need to be more specific?
> > > >
> > > 
> > > What exactly isn't working?
> > > 
> > > Is dev1 a group, or an individual?
> > > 
> > > Do you have the case of the path matched exactly?
> The rules
> > > are case-sensitive.
> > > 
> > 
> > I am able to commit with a login that is in the dev
> group that is not in the dev1 group.
> > 
> > The actual path is /svnrepo/ABC/DEF so I tried
> > 
> > [/svnrepo/sandbox/tags]
> > @dev1 = rw
> > 
> > and that doesn't work either. Based on the example in
> the file I also tried
> > 
> > [repository:/svnrepo/sandbox/tags]
> > @dev1 = rw
> > 
> > with no luck. Any ideas as to what I am doing wrong?
> 
> You'll need to tighten permissions for the 'dev' group in
> /ABC/DEF also.
> [/]
> @dev = rw
> @qa = r
> 
> [/ABC/DEF]
> @dev = r      
> @dev1 = rw
> 
> See this snippet from
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
>   "Of course, permissions are inherited from parent to
> child directory.
>   That means we can specify a subdirectory with a
> different access policy
>   for Sally:
>   
>   [calc:/branches/calc/bug-142]
>   harry = rw
>   sally = r
>   
>   # give sally write access only to the 'testing'
> subdir
>   [calc:/branches/calc/bug-142/testing]
>   sally = rw
>   
>   Now Sally can write to the testing subdirectory of
> the branch, but can
>   still only read other parts. Harry, meanwhile,
> continues to have
>   complete read/write access to the whole branch."
> 
> The same applies when restricting access, rather than
> expanding it.
> 

I realize my explanation is wrong, my apologies. It is actually repo ABC with 
40+ folders under it. I want to limit who has access to one of the folders 
(DEF). After looking at the svnbook, I thought the following would work but it 
is still not working:

[ABC:/DEF]
@dev = r
@dev1 = rw

Re: Limited subdirectory access

[Johan Corveleyn]

On Mon, Jan 30, 2012 at 10:55 PM, K F  wrote:
>
>
> --- On Mon, 1/30/12, Stefan Sperling  wrote:
>
>> From: Stefan Sperling 
>> Subject: Re: Limited subdirectory access
>> To: "K F" 
>> Cc: "Andy Levy" , users@subversion.apache.org
>> Date: Monday, January 30, 2012, 9:32 PM
>> On Mon, Jan 30, 2012 at 01:14:53PM
>> -0800, K F wrote:
>> > --- On Mon, 1/30/12, Andy Levy 
>> wrote:
>> > > have it setup in the authz file now:
>> > > > [/]
>> > > > @dev = rw
>> > > > @qa = r
>> > > >
>> > > > [/ABC/DEF]
>> > > > @dev1 = rw
>> > > >
>> > > > Do I need to be more specific?
>> > > >
>> > >
>> > > What exactly isn't working?
>> > >
>> > > Is dev1 a group, or an individual?
>> > >
>> > > Do you have the case of the path matched exactly?
>> The rules
>> > > are case-sensitive.
>> > >
>> >
>> > I am able to commit with a login that is in the dev
>> group that is not in the dev1 group.
>> >
>> > The actual path is /svnrepo/ABC/DEF so I tried
>> >
>> > [/svnrepo/sandbox/tags]
>> > @dev1 = rw
>> >
>> > and that doesn't work either. Based on the example in
>> the file I also tried
>> >
>> > [repository:/svnrepo/sandbox/tags]
>> > @dev1 = rw
>> >
>> > with no luck. Any ideas as to what I am doing wrong?
>>
>> You'll need to tighten permissions for the 'dev' group in
>> /ABC/DEF also.
>> [/]
>> @dev = rw
>> @qa = r
>>
>> [/ABC/DEF]
>> @dev = r
>> @dev1 = rw
>>
>> See this snippet from
>> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
>>   "Of course, permissions are inherited from parent to
>> child directory.
>>   That means we can specify a subdirectory with a
>> different access policy
>>   for Sally:
>>
>>   [calc:/branches/calc/bug-142]
>>   harry = rw
>>   sally = r
>>
>>   # give sally write access only to the 'testing'
>> subdir
>>   [calc:/branches/calc/bug-142/testing]
>>   sally = rw
>>
>>   Now Sally can write to the testing subdirectory of
>> the branch, but can
>>   still only read other parts. Harry, meanwhile,
>> continues to have
>>   complete read/write access to the whole branch."
>>
>> The same applies when restricting access, rather than
>> expanding it.
>>
>
> I realize my explanation is wrong, my apologies. It is actually repo ABC with 
> 40+ folders under it. I want to limit who has access to one of the folders 
> (DEF). After looking at the svnbook, I thought the following would work but 
> it is still not working:
>
> [ABC:/DEF]
> @dev = r
> @dev1 = rw

Can you check if order of the rules matters? Either putting this rule
with [ABC:/DEF] before or after the other one (for [ABC:/]). I'm not
sure, but I vaguely remember some prior discussion about this ...

-- 
Johan

Re: Limited subdirectory access

[K F]

--- On Mon, 1/30/12, Johan Corveleyn  wrote:

> From: Johan Corveleyn 
> Subject: Re: Limited subdirectory access
> To: "K F" 
> Cc: "Stefan Sperling" , "Andy Levy" , 
> users@subversion.apache.org
> Date: Monday, January 30, 2012, 10:13 PM
> On Mon, Jan 30, 2012 at 10:55 PM, K F
> 
> wrote:
> >
> >
> > --- On Mon, 1/30/12, Stefan Sperling 
> wrote:
> >
> >> From: Stefan Sperling 
> >> Subject: Re: Limited subdirectory access
> >> To: "K F" 
> >> Cc: "Andy Levy" ,
> users@subversion.apache.org
> >> Date: Monday, January 30, 2012, 9:32 PM
> >> On Mon, Jan 30, 2012 at 01:14:53PM
> >> -0800, K F wrote:
> >> > --- On Mon, 1/30/12, Andy Levy 
> >> wrote:
> >> > > have it setup in the authz file now:
> >> > > > [/]
> >> > > > @dev = rw
> >> > > > @qa = r
> >> > > >
> >> > > > [/ABC/DEF]
> >> > > > @dev1 = rw
> >> > > >
> >> > > > Do I need to be more specific?
> >> > > >
> >> > >
> >> > > What exactly isn't working?
> >> > >
> >> > > Is dev1 a group, or an individual?
> >> > >
> >> > > Do you have the case of the path matched
> exactly?
> >> The rules
> >> > > are case-sensitive.
> >> > >
> >> >
> >> > I am able to commit with a login that is in
> the dev
> >> group that is not in the dev1 group.
> >> >
> >> > The actual path is /svnrepo/ABC/DEF so I
> tried
> >> >
> >> > [/svnrepo/sandbox/tags]
> >> > @dev1 = rw
> >> >
> >> > and that doesn't work either. Based on the
> example in
> >> the file I also tried
> >> >
> >> > [repository:/svnrepo/sandbox/tags]
> >> > @dev1 = rw
> >> >
> >> > with no luck. Any ideas as to what I am doing
> wrong?
> >>
> >> You'll need to tighten permissions for the 'dev'
> group in
> >> /ABC/DEF also.
> >> [/]
> >> @dev = rw
> >> @qa = r
> >>
> >> [/ABC/DEF]
> >> @dev = r
> >> @dev1 = rw
> >>
> >> See this snippet from
> >> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
> >>   "Of course, permissions are inherited from
> parent to
> >> child directory.
> >>   That means we can specify a subdirectory with a
> >> different access policy
> >>   for Sally:
> >>
> >>   [calc:/branches/calc/bug-142]
> >>   harry = rw
> >>   sally = r
> >>
> >>   # give sally write access only to the 'testing'
> >> subdir
> >>   [calc:/branches/calc/bug-142/testing]
> >>   sally = rw
> >>
> >>   Now Sally can write to the testing subdirectory
> of
> >> the branch, but can
> >>   still only read other parts. Harry, meanwhile,
> >> continues to have
> >>   complete read/write access to the whole
> branch."
> >>
> >> The same applies when restricting access, rather
> than
> >> expanding it.
> >>
> >
> > I realize my explanation is wrong, my apologies. It is
> actually repo ABC with 40+ folders under it. I want to limit
> who has access to one of the folders (DEF). After looking at
> the svnbook, I thought the following would work but it is
> still not working:
> >
> > [ABC:/DEF]
> > @dev = r
> > @dev1 = rw
> 
> Can you check if order of the rules matters? Either putting
> this rule
> with [ABC:/DEF] before or after the other one (for [ABC:/]).
> I'm not
> sure, but I vaguely remember some prior discussion about
> this ...
> 
> -- 
> Johan
> 

I tried swapping the order and that didn't work either. Am I stating it 
correctly?

[ABC:/DEF]
@dev = r
@dev1 = rw

Do I need the ABC in the front?

Re: Limited subdirectory access

[Daniel Shahaf]

Johan Corveleyn wrote on Mon, Jan 30, 2012 at 23:13:17 +0100:
> Can you check if order of the rules matters? Either putting this rule
> with [ABC:/DEF] before or after the other one (for [ABC:/]). I'm not
> sure, but I vaguely remember some prior discussion about this ...

Aren't they parsed into a hash?

Anyway: [foo:/bar] has priority over [/bar].

Unable to checkout/add hidden files to repo

[Jon Grimes]

Hello,

I'm having a strange problem and because it has to do with hidden files I'm
having a real hard time finding any information about it.  everything
is usually about the .svn folders.

Essentially my repository wont let me check out or commit any hidden files.
(.htaccess)

When i checkout a folder with a hidden file already in it, the hidden files
are not downloaded in my working copy.

When i do an 'svn ls' the hidden files are shown in the list of files and
they also appear in websvn.

When i create a new hidden file and try to svn add and commit it i get an
error like the following:

"svn:
'/svn/repo/!svn/wrk/3bc21418-b253-41a7-8d7c-dd2db27c6e5b/path/path/.hidden'
path not found"

I've never had this issue and i cant find any information on it.  This repo
has been running with no issues for years now and no changes have been made
to it configuration as far as i can tell.

The server is running debian lenny with svn 1.5.1

Any help would really be appreciated

Thanks,

PS:  please be sure to CC me on replies,  I am not subscribed:
jon.gri...@gmail.com

Jon Grimes

1340 Home Ave. STE A
Akron, OH 44310
Toll Free: 800-493-3450
Fax: 800-446-5906

Re: svn status returns incorrect results on Windows 7

[Justin Johnson]

On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko
 wrote:
> 2012/1/27 Justin Johnson :
>> Hi,
>>
>> I am running Subversion 1.7.2 64 bit installer from CollabNet on
>> Windows 7.  The problem I'm experiencing can be seen in the output
>> below.  In summary, svn status is returning incorrect results,
>> sometimes not showing that something has been modified and sometimes
>> not recognizing that I'm in a working copy.  This happens for me no
>> matter how many times I recreate the working copy, and it happens if I
>> store the working copy in C:\Users... as below or in C:\work.  I do
>> not have the same problem when trying to reproduce the problem with
>> svn 1.7.2 on Solaris.
>>
>> PS C:\Users\myuser\wc> svn st
>> M       a\b\file.txt
>> PS C:\Users\myuser\wc> cd a
>> PS C:\Users\myuser\wc\a> svn st
>> PS C:\Users\myuser\wc\a> cd b
>> PS C:\Users\myuser\wc\a\b> svn st
>> svn: warning: W155007: '.' is not a working copy
>>
>> Does anyone know why this is happening?  I searched for this problem
>> and only found TortoiseSVN users complaining about it, and some
>> suggestions to make sure the user has full control of the filesystem.
>> I did this without resolution, but decided to post here since it is a
>> Subversion issue (with Windows 7 perhaps) and not a TortoiseSVN issue.
>>
>
> It can happen because of wrong capitalization in the path.
>
> Are "a" and "b" real names? Are you able to reproduce this with the
> Greek tree (repro-template.bat) [1]? Did you do the checkout with
> command-line client or with Tortoise?
>
>
> AFAIK, Tortoise 1.7.3+ does some additional work to normalize paths
> before passing them to Subversion library methods. (TSVN issue 156.
> There was notorious bug in that code - issue 169. Fixed in TSVN 1.7.4
> [2]).
>
> In my experience Windows command shell also does some normalization
> when I do "cd" command.
>
>
> [1] 
> http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
> [2] http://code.google.com/p/tortoisesvn/issues/detail?id=156
> http://code.google.com/p/tortoisesvn/issues/detail?id=169
>
> Best regards,
> Konstantin Kolinko

Thank you so much for the reply.  It *does* have to do with
capitalization.  I never would have guessed that.  If I cd into
directories and always use the correct case, the commands work fine
every time.  If I cd into a path using the incorrect case, I of course
am able to cd but then svn doesn't return the correct results.

Does anyone know if there are plans to fix this behavour in Subversion
as opposed to working around them in TortoiseSVN?

update failed

[priest]

> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> with as much information as possible about what
> you were trying to do.
> But please first search the mailing list archives for the error message
> to avoid reporting the same problem repeatedly.
> You can find the mailing list archives at
> http://subversion.apache.org/mailing-lists.html
>
> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using Ctrl-C):
>
> In file
>  
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.4\ext\subversion\subversion\libsvn_wc\update_editor.c'
>  line 1583: assertion failed (action == svn_wc_conflict_action_edit ||
> action
>  == svn_wc_conflict_action_delete || action ==
> svn_wc_conflict_action_replace)
> ---
> 确定
> ---

Can relocate from a svnserve based server that was 'svn sync' to a new http based server

[Brent Webster]

I have numerous large svn repositories accessible by svnserve on an older linux 
server that I'm moving to a new VMWare VM server using http authentication.  
I'm using svnsync to transfer the older "svn://" repositories to the new 
"http://"; repositories.  The problem that I'm having is trying to "relocate" 
the existing checked out "svn://" based working copy and point it to the new 
"http://"; repository.  An example existing WC:
svn@svna: svn info
Path: .
Working Copy Root Path: /home/svn/bin
URL: svn://svnrepo/BelAir/admin/main/svnserver/bin
Repository Root: svn://svnrepo/BelAir/admin
Repository UUID: ad8b7147-7818-0410-a3fb-ed15fa4e4e0d
Revision: 256
Node Kind: directory
Schedule: normal
Last Changed Author: bwebster
Last Changed Rev: 256
Last Changed Date: 2012-01-30 16:38:51 -0500 (Mon, 30 Jan 2012)

I've tried numerous command syntax combinations like
svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin 
svn://svnrepo/BelAir/admin/main/svnserver/bin
svn relocate svn://svnrepo/BelAir/admin/main/svnserver/bin 
http://svnrepo2:18080/svn/admin/main/svnserver/bin
svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin .

This is the type of error message:
svn@svna: svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin .
svn: E195009: The repository at 
'http://svnrepo2:18080/svn/admin/main/svnserver/bin' has uuid 
'65d03f8f-4f6b-4b7c-8505-7ddab04e9aed', but the WC has 
'ad8b7147-7818-0410-a3fb-ed15fa4e4e0d'

What am I doing wrong (i.e. hopefully I'm doing something wrong).

Thanks Brent




This email, including any attachments, may contain confidential information, 
privileged material (including material protected by solicitor-client and/or 
other applicable privileges) or constitute non-public information under 
securities law(s). Any exploitation of the information contained in this email 
(including any attachments) by anyone other than the intended recipient is 
prohibited. If you have received this email in error, please reply to the 
sender and delete this information from your system as soon as reasonably 
practicable. Use, dissemination, distribution, reproduction, publication or any 
other exploitation of this email by unintended recipients is not authorized and 
may be unlawful.

Re: Can relocate from a svnserve based server that was 'svn sync' to a new http based server

[Lorenz]

Brent Webster wrote:
>[...] I'm using svnsync to transfer the older "svn://" repositories to the new 
>"http://"; repositories
>The problem that I'm having is [...]
>svn: E195009: The repository at 
>'http://svnrepo2:18080/svn/admin/main/svnserver/bin' has
> uuid '65d03f8f-4f6b-4b7c-8505-7ddab04e9aed', but the WC has 
> 'ad8b7147-7818-0410-a3fb-ed15fa4e4e0d'

every repository gets a unique ID (uuid) on creation.
But to be able to svn relocate, your new repo needs to have same uuid
as the old one

See
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.uuids
for more information.
-- 

Lorenz