What does "Repository moved temporarily " mean?
Hi One of our users tried to copy between repositories and got error: "svn: Repository moved temporarily to 'https://[snip] please relocate" We understand that such copying is disallowed, but please will someone explain what "Repository moved temporarily" means in this context? Is it possible that some temporary files have been created somewhere? Best regards David
Re: long path names on windows prefixed with \\?\ not handled by svn commands
Hello Bert, yes, confirmed, providing absolute paths without the prefix \\?\ works. As you mention, we just have to know which function requires the prefix, or has it implicit or does not support it at all. Thanks for your clarification. Heinz On 11.05.2010, at 21:57, Bert Huijben wrote: Subversion uses the APR library which handles the escaping for specific API functions that allow this trick. The ‘\\?\’ style paths are not a different path, but just the original path escaped for a specific api. (Some Windows APIs allow this trick, others just support long paths directly and then there are functions that support neither. By passing the long path yourself you assume that all filesystem functions have this long path support) If you pass absolute paths to svn, it should support long paths directly. (Windows doesn’t support long relative paths). Subversion 1.7 will probably work better with long relative paths, as it will use absolute paths internally for almost every operation. Bert From: Heinz Prantner [mailto:heinz.prant...@opensynergy.com] Sent: dinsdag 11 mei 2010 14:21 To: users@subversion.apache.org Subject: long path names on windows prefixed with \\?\ not handled by svn commands Hello, running svn client commands other than svn checkout on windows fail, if the path name (of the local working copy location) is prefixed with \\?\. The prefix is required for path names longer than 255 or so. It seems that svn commands like svn info or svn status behave different than svn checkout command regarding the path name prefix. example: svn info \\?\c:\long\path\name svn: '\' is not a working copy Any thoughts? (I am using svn client version 1.6.11 from CollabNet) Thanks, Heinz Heinz Prantner Senior Software Design Engineer OpenSynergy GmbH Rotherstr. 9, 10245 Berlin t: +49 (30) 20 1818 35-23 f: +49 (39) 20 1818 35-02 m: +49 (179) 23 63 588 e: heinz.prant...@opensynergy.com w: www.opensynergy.com Handelsregister: Amtsgericht Charlottenburg, HRB 108616B Geschäftsführung: Frank-Peter Böhm, Stefaan Sonck Thiebaut, Rolf Morich
RE: Best practice for moving folders around?
Many thanks Ulrich for your input... > -Original Message- > From: Ulrich Eckhardt [mailto:eckha...@satorlaser.com] > Sent: 11 May 2010 16:33 > > On Tuesday 11 May 2010, Cooke, Mark wrote: > > Can I ask your suggestions on how best to correct the following > > scenario: > > > > In a new repository we checked a version of the product code into > > 'trunk' (moving projects from VSS, finally). > > Just for the record: There are tools that preserve some > history, in case you care. > We converted the whole archive using vss2svn (this one: http://code.google.com/p/vss2svn/ there seem to be 2 projects with that name!) which worked reasonably well. However, we decided to split the projects into separate repos (with associated Trac sites) and the effort to dumpfilter all the bits out was deemed too much for the little gain. So we just keep the import available read-only for reference. > > This was cp'd to 'tags'/tag1. > > A normal tagging operation, okay. > > > A new svn user then cp'd 'tags'/tag1 to 'tags'/tag2 and > > checked this out as a working copy: > > > > [project] -> 'trunk' > > 'trunk' -> 'tags'/tag1 > > 'tags'/tag1 -> 'tags'/tag2 > > 'tags'/tag2 -> (wc) > > (wc) -> 'tags'/tag2 > > Generally, tags are points in time, they are not intended for > development and should be treated as immutable. There are even > pre-commit hooks that enforce this. However, there is nothing > that could stop the user from creating a working copy of it, > only from committing to the repository. > Good idea, I Have no hooks setup as yet, I will look into this. Otherwise, yes, it is mainly an education issue... > > Several updates later we have discussed the idea of what is > > a 'tag', 'branch' and the 'trunk' and have decided that the > > development should have occurred in 'trunk' (small teams of > > one or two so no perceived need for developer branches) and > > that we should create a new 'tags'/tag2 for the release > > version. > > Yes, development should have taken place either in trunk or > in a separate branch. What you can do now depends on where you > are and what you did in between > > 1. If "tag2" was not modified and trunk was not modified > either (only local changes to the working copy), you could > switch (svn switch) your working copy to the trunk and commit > from there. You could then delete the tag, there isn't anything > in there that happened anyway. > ...development has been committed... > 2. If the trunk was not modified, you could simply delete the > project therein and move "tag2" in its place. Looking at the > history, you will see that the location of the project jumps > a bit around though, in case you care. > ...this case applies, but... > 3. If the developer already committed his changes to the tag, > and others committed to trunk, you should merge those changes > into trunk instead. For that, you first declare the tag as a > branch and move it to the "branches" folder. Then, you simply > merge the revisions you want to the trunk. This is not different > from the normal everyday merge that you do from a feature > branch to your trunk and explained in the manual. Note that > the developer must switch (svn switch) his working copy which > still points at the tag, either at the branch or at trunk. > ...no other changes to 'trunk' have occurred... > > How do we best achieve this, preserving as much history as > > possible? I can think of several possible solutions: > > > > 1) merge 'tags'/tag2 into trunk, delete 'tags'/tag2 then > >create new 'tags'/tag2 from trunk? > > > > 2) delete 'trunk', move 'tags'/tag2 to become 'trunk', > >create new tag > > > > 3) I'm sure I could think of worse ideas > > Actually, I would suggest merging the changes. Firstly, it > documents that the changes were made in isolation. Secondly, > it keeps the continuity of trunk. Lastly, you get familiar > with branching and merging. In any case, you should delete > or move "tag2", because it is not a tag. > I agree with all your points, so I propose we will (a) move the offending tag2 to 'branches', relocating the wc to the new location, (b) merge the changes into 'trunk' to reinforce the idea that that should be where development continues and then (c) create a new tag2 from the trunk. > > using latest tortoise from windoze clients. > > Right-click, submenu, "Merge...". This will guide you through > the merge process. Select "tag2" as source URL and a (clean) > working copy of the trunk as target. Ignoring line ending and > whitespace sometimes helps, or merging smaller ranges. Always > merge and commit the root project folder, so you only have > "svn:mergeinfo" property in one place. > Thanks for the useful guide, we will have a go and, hopefully, report success. > Good luck! > Once again, many thanks for your time. ~ mark c
Free Online Subversion Training - All About Subversion Hook Scripts
svn.wandisco.com/hookscripts Hook scripts are server-side executables tied to various Subversion events. During this course, attendees will learn how to use hook scripts for: * Email notification of an event * Commit validation * Automatic backup of changes * Integration with issue trackers and other external systems. * Specific access control scenarios * And much more Broadcast Details Wed, May 19, 2010 9:00 am PDT
svn update and permissions
Hi,
An svn update process doesn roughtly this :
open("tempfile.tmp", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666)
write() tempfile.tml
rename("tempfile.tmp", "targetfile");
While this works, it has one problem : The rename recreated the file,
and thus applies default permissions. While this is OK in most situations,
it isn't in some. Does this have a specific reason, and is changing the
behaviour to a truncate() and write() a good alternative ?
Regards,
Igmar
Re: Best practice for moving folders around?
Cooke, Mark wrote: Good idea, I Have no hooks setup as yet, I will look into this. Otherwise, yes, it is mainly an education issue... Note that making mistakes is fairly normal, so one thing you should work out is a scheme to track the tags that you care about. You probably want some human-friendly name and numbering scheme where you copy the trunk or branch versions you expect to be interested in - and you should expect some of these to have various problems and you'll just ignore them later. On the other hand if you are just getting started and want to clean up, you could probably svnadmin dump the repository, svnadumpfilter including only tags2, then make a new repository with trunk/tags/branches directories and svnadmin load your history with trunk as the parent directory. -- Les Mikesell lesmikes...@gmail.com
Update of missing on non-working directory
Hi, I think the exit code subversion returns isn't right, it should indicate an error $ svn --version svn, version 1.6.11 (r934486) $ svn update /blah-blah Skipped '/blah-blah' $ echo $? 0 $ svn update /etc Skipped '/etc' $ echo $? 0 Vadym
Re: Update of missing on non-working directory
On Wed, May 12, 2010 at 09:23, Vadym Chepkov wrote: > Hi, > > I think the exit code subversion returns isn't right, it should indicate an > error > > $ svn --version > svn, version 1.6.11 (r934486) > > > $ svn update /blah-blah > Skipped '/blah-blah' > $ echo $? > 0 > > $ svn update /etc > Skipped '/etc' > $ echo $? > 0 Why? The command executed successfully and reported what it did. Skipping something which is not a working copy isn't a program error; attempting to update a something which is not a WC is a user error.
Re: Update of missing on non-working directory
Consider this: $ svn -q --non-interactive update /blah-blah $ echo $? 0 No output even to stderr, no indication of a failure at all. Subversion doesn't always used interactively, hence --non-interactive switch. If you made a mistake in a script it will be unnoticed (well, this was my unpleasant surprise) Vadym On May 12, 2010, at 9:28 AM, Andy Levy wrote: > On Wed, May 12, 2010 at 09:23, Vadym Chepkov wrote: >> Hi, >> >> I think the exit code subversion returns isn't right, it should indicate an >> error >> >> $ svn --version >> svn, version 1.6.11 (r934486) >> >> >> $ svn update /blah-blah >> Skipped '/blah-blah' >> $ echo $? >> 0 >> >> $ svn update /etc >> Skipped '/etc' >> $ echo $? >> 0 > > Why? The command executed successfully and reported what it did. > Skipping something which is not a working copy isn't a program error; > attempting to update a something which is not a WC is a user error.
Problem with "bogus date" on NFS
Hi, I have a strange problem with a working copy on a NFS mount. Checking out works fine, but whenever I try to svn stat/info/up a certain directory, I get the message svn: Error at entry 6 in entries file for 'cfg': svn: Bogus date I traced it down to an empty file in this directory that has a weird "text last changed" date in the entries file: 1949-12-07T10:27:14.-840919Z This date is different (random) each time I make a new checkout on the NFS mount. But everything is fine when I check out the repository on a local disk. I tried removing, committing and re-adding the offending file, but that doesn't fix the problem. Any ideas what is going on there? My svn version is 1.5.7 (r36142). Thanks! Andreas
RE: What does "Repository moved temporarily " mean?
> "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: What does "Repository moved temporarily " mean?
Hi Chris, Yes we do go through a proxy, so maybe your explanation is correct. I haven't tried running it twice in a row but, since it's an invalid command, I am not sure that that would make much difference. BR David
Attempting a transparent(ish) write-through proxy for a remote site.
Hi all, I've been trying to set up mirror repository for a remote site. So far, I have everything running: The mirror repository, the proxy URL (separate from the mirror to avoid sync loops) and the post-commit and post-revprop-change synchronisation hooks are all working well. I'm able to check out from the mirror URL on the remote site and have commits routed back through to the master. The final part I'm having trouble with is setting it up so that the remote users can use the same repository URL as the local ones. We have a number of repos with developers moving form project to project at any given time and potentially moving between sites. It would be very useful to have the documentation for each project supply only a single URL which would work from either site, with the proxy only coming in to action when they're working remotely. Ideally, this would be completely transparent, but that doesn't look to be possible. I'd be happy if I could supply a client config file to remote users that would ensure they use the write-through proxy for all mirrored repositories. Using the following setup: Master URL: http://svnmaster/project Mirror URL: http://svnmirror:8080/project Proxy URL: http://svnproxy:8000/project I've set the 'servers' config to: http-proxy-host = svnproxy http-proxy-port = 8000 I've also tried specifying them on the command line: svn co http://svnmaster/project --config-option servers:global:http-proxy-host=svnproxy --config-option servers:global:http-proxy-port=8000 In both attempts, the proxy is ignored and the client connects directly to the master. None of the guides I've read mention much about configuring clients in this way, and I've a feeling I'm mis-using the general connection proxy settings, which is why it's not working; but I can't see any other way of achieving my aim. Have I missed something or is this not currently possible? Cheers, Terry.
using saslauthd for user authendication
Hello, I have a working LDAP-Server and some svn-repositories on an second server. The svnserv uses the "passwd" file at the moment for user authendication. Now I like to to use the LDAP instead. Because the handbook says, svnserv could be used with sasl to access a LDAP-server, I have set up a "saslauthd" on the svn-server. The saslauthd asks the LDAP over SSL if the given user is in a svn-group. This is working fine so far, I can check this with: # sudo /usr/sbin/testsaslauthd -u USERNAME -p PASSWORD whitch returns either 0: OK "Success." or 0: NO "authentication failed" Now I have set up a "/usr/lib/sasl2/svn.conf", but I'm not shure, what to fill in. The lines from the svnhandbook are redirecting to a "/etc/sasldb2", which I have. But I don't want to use a database-file, the svnserv should request the localy running saslauthd. It is possible to do something like that, or are I comlpetely misunderstood the svnserver sasl-support? (A further point is, that "svnserve --version" on ubuntu 8.04 does not return something like "sasl", so it seems that I anyway need to compile it my own.) Thank you in advance very much! Regards Sebastian -- Sebastian Kotthoff Rechenzentrum Universität Mannheim B6, 23-29; Building B; Room 1.16 68159 Mannheim Tel: +49 621 181 2516 Fax: +49 621 181 2682
Re: Apache + SVN (+ LDAP) don't works
To simplify the thread, I removed the LDAP entries! Now a config without authentication and returning "client denied by server configuration" message: 1. 2. 3. ServerAdmin m...@me.com 4. ServerName my.server.net 5. 6. ErrorLog /var/log/apache2/subversion.my.server.net-error_log 7. CustomLog /var/log/apache2/subversion.my.server.net-access_log combined 8. 9. DocumentRoot /var/www 10. 11. LogLevel debug 12. 13. 14. DAV svn 15. 16. SVNParentPath /home/files/svn_root 17. SVNListParentPath on 18. 19. # Enable WebDAV automatic versioning 20. SVNAutoversioning On 21. 22. # Repository Display Name 23. SVNReposName "Subversion Repository" 24. 25. 26. 27. Order allow,deny 28. Allow from all 29. 30. 31. 32. Order allow,deny 33. Allow from all 34. 35. 36.
Re: Problem with "bogus date" on NFS
On May 12, 2010, at 6:55 AM, Andreas Schwarz wrote: > > Hi, > > I have a strange problem with a working copy on a NFS mount. Checking > out works fine, but whenever I try to svn stat/info/up a certain > directory, I get the message > svn: Error at entry 6 in entries file for 'cfg': > svn: Bogus date > I traced it down to an empty file in this directory that has a weird > "text last changed" date in the entries file: > 1949-12-07T10:27:14.-840919Z > This date is different (random) each time I make a new checkout on the > NFS mount. But everything is fine when I check out the repository on a > local disk. > > I tried removing, committing and re-adding the offending file, but that > doesn't fix the problem. > > Any ideas what is going on there? Are you by any chance using NFSv4, and mounting this filesystem from a Solaris NFS server? I encountered the same issue a few months ago. It appears to only happen with zero-length files, because as soon as data is written to the file the timestamp gets fixed. It's actually a Solaris bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6854659 One workaround is to use NFSv3. Another is to put some data in the zero-length file. The fix is in snv_126, which means it should be fixed in the next version of OpenSolaris that comes out (the one that was supposed to be 2010.03, before the Oracle merger delayed everything.) -- David Brodbeck System Administrator, Linguistics University of Washington
Re: using saslauthd for user authendication
On Wed, May 12, 2010 at 6:01 PM, Sebastian Kotthoff wrote: > Hello, > > I have a working LDAP-Server and some svn-repositories on an second server. > The svnserv uses the "passwd" file at the moment for user authendication. > Now I like to to use the LDAP instead. > Because the handbook says, svnserv could be used with sasl to access > a LDAP-server, I have set up a "saslauthd" on the svn-server. > The saslauthd asks the LDAP over SSL if the given user is in a svn-group. > > This is working fine so far, I can check this with: > # sudo /usr/sbin/testsaslauthd -u USERNAME -p PASSWORD > whitch returns either > 0: OK "Success." or 0: NO "authentication failed" > > Now I have set up a "/usr/lib/sasl2/svn.conf", but I'm not shure, > what to fill in. The lines from the svnhandbook are redirecting to a > "/etc/sasldb2", which I have. But I don't want to use a database-file, > the svnserv should request the localy running saslauthd. > > It is possible to do something like that, or are I comlpetely misunderstood > the svnserver sasl-support? > > (A further point is, that "svnserve --version" on ubuntu 8.04 does not return > something like "sasl", so it seems that I anyway need to compile it my own.) > > Thank you in advance very much! The following recent thread from this mailinglist may help you: http://svn.haxx.se/users/archive-2010-03/0515.shtml The discussion eventually resulted in a working setup of svnserve + SASL + LDAP. Cheers, -- Johan
RE: Apache + SVN (+ LDAP) don't works
> 1. > 2. > 3. ServerAdmin m...@me.com > 4. ServerName my.server.net > 5. > 6. ErrorLog /var/log/apache2/subversion.my.server.net-error_log > 7. CustomLog /var/log/apache2/subversion.my.server.net-access_log > combined > 8. > 9. DocumentRoot /var/www > 10. > 11. LogLevel debug > 12. > 13. What happens if you remove that trailing whack? BOb > 14. DAV svn > 15. > 16. SVNParentPath /home/files/svn_root > 17. SVNListParentPath on > 18. > 19. # Enable WebDAV automatic versioning > 20. SVNAutoversioning On > 21. > 22. # Repository Display Name > 23. SVNReposName "Subversion Repository" > 24. > 25. > 26. > 27. Order allow,deny > 28. Allow from all > 29. > 30. > 31. > 32. Order allow,deny > 33. Allow from all > 34. > 35. > 36.
Re: Update of missing on non-working directory
Why? The command executed successfully and reported what it did. "ls /blah-blah ." successfully lists the . directory, but still returns an error code because of the user error in its first argument. There may be a reason why svn chooses to almost ignore bad input but it's a surprise for sure. -- Stein
