Problem
I have installed: TortoiseSVN 1.8.2, Build 24708 - 64 Bit , 2013/08/27 19:20:39 Subversion 1.8.3, -release apr 1.4.8 apr-util 1.5.2 serf 1.3.1 OpenSSL 1.0.1e 11 Feb 2013 zlib 1.2.8 The problem is caused when i do an update. The directory is structured by hierarchy and several directory are unaccessible by me because my user is blocked. I think the problem derivate to the directory unaccessible because if I elevate my user the problem do not exist anymore. I did a series of tests: - the cleanup command do not solve the problem. Also the cleanup on the root do not resolve - if i delete the .svn and I do a checkout, the problem do not exist anymore until there is a new change in the repository. - the problem is present in all account with restricted access and not present on users with no restriction The problem was not present on version 1.6.x Thanks very much --- 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.8.2\ext\subversion\subversion\libsvn_wc\update_editor.c' line 3046: assertion failed (status != svn_wc__db_status_normal) --- OK ---
Re: Problem
Guten Tag odd oddorks, am Mittwoch, 4. September 2013 um 09:33 schrieben Sie: > I think the problem derivate to the directory unaccessible because > if I elevate my user the problem do not exist anymore. [...] > The problem was not present on version 1.6.x I can't believe that a switch in your version of Subversion changes anything regarding access permissions in your working copy. Subversion 1.8 could even be more compatible because it only needs write access to one svn folder. Are you really sure nothing else changed the permissions in your working copy? What do the permissions look like at all? Where are the working copies stored, in your home directory or elsewhere? I have a restricted user myself and dozens of working copies and no problems with permissions. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Problem
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: woensdag 4 september 2013 12:25 > To: users@subversion.apache.org > Subject: Re: Problem > > Guten Tag odd oddorks, > am Mittwoch, 4. September 2013 um 09:33 schrieben Sie: > > > I think the problem derivate to the directory unaccessible because > > if I elevate my user the problem do not exist anymore. > [...] > > The problem was not present on version 1.6.x > > I can't believe that a switch in your version of Subversion changes > anything regarding access permissions in your working copy. Subversion > 1.8 could even be more compatible because it only needs write access > to one svn folder. Are you really sure nothing else changed the > permissions in your working copy? What do the permissions look like at > all? Where are the working copies stored, in your home directory or > elsewhere? > > I have a restricted user myself and dozens of working copies and no > problems with permissions. Just a guess: Do you have file externals in this working copy? And if yes: Is one of these affected by the update? (Perhaps something was added in its place?) Bert
RE: Problem
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: woensdag 4 september 2013 18:16 > To: 'Thorsten Schöning'; users@subversion.apache.org > Subject: RE: Problem > > > > > -Original Message- > > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > > Sent: woensdag 4 september 2013 12:25 > > To: users@subversion.apache.org > > Subject: Re: Problem > > > > Guten Tag odd oddorks, > > am Mittwoch, 4. September 2013 um 09:33 schrieben Sie: > > > > > I think the problem derivate to the directory unaccessible because > > > if I elevate my user the problem do not exist anymore. > > [...] > > > The problem was not present on version 1.6.x > > > > I can't believe that a switch in your version of Subversion changes > > anything regarding access permissions in your working copy. Subversion > > 1.8 could even be more compatible because it only needs write access > > to one svn folder. Are you really sure nothing else changed the > > permissions in your working copy? What do the permissions look like at > > all? Where are the working copies stored, in your home directory or > > elsewhere? > > > > I have a restricted user myself and dozens of working copies and no > > problems with permissions. > > Just a guess: > > Do you have file externals in this working copy? > > And if yes: Is one of these affected by the update? (Perhaps something was > added in its place?) Or there is an explicit authz setting in the repository that nothing can be added in its place? Bert
how to switch without losing files
I have a branch with directories a, b, and c. I have another branch with directorys b and c (a is missing). I checkout from the 1st branch, and have in my working copy directories a, b, and c. I do an svn switch to the 2nd branch, using svn switch --force --accept mine-full ..., and I see messages like: D path-to-a and when I look, the switch has deleted the a directory in my working copy. Is there a way to have the switch keep from deleting "a"? So when I switch back, later, to the 1st branch where a exists, it can commit just the changes in that tree? -Marshall Schor
Multiple Apache webdav servers sharing repositories via NFS
I've done several searches, and have found old and conflicting responses to the question of sharing a repository via NFS. So what is the current set of concerns with sharing repositories using NFS among several web servers? Here is the scenario, several hundred repositories shared via NFS to a couple of webdav (Apache mod-svn) servers. The Apache servers set up via a round-robin DNS server (thus they are all sharing a common virtualhost name). All user access is via webdav (authentication and access controlled by an Apache authentication handler). The users will see a common hostname for all repositories. All the servers are "network close" to each other. Assuming that the NFS is current (NFS 4) with subtree checking disabled (as per the FAQ), are there any gotcha's or other concerns. I currently have a solution using some custom Apache proxying that is working, but I'm looking at trying to simplify my solution.
Re: how to switch without losing files
Guten Tag Marshall Schor, am Mittwoch, 4. September 2013 um 23:03 schrieben Sie: [...] > and when I look, the switch has deleted the a directory in my working copy. Because --force. > Is there a way to have the switch keep from deleting "a"? So when I switch > back, later, to the 1st branch where a exists, it can commit just the changes > in > that tree? No, not using --force would result in a staying unversioned in your working copy, but on switching back to a branch where a already exists this would lead to a tree conflict. There was a lengthy discussion about that recently. http://www.mail-archive.com/users@subversion.apache.org/msg19000.html Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
