svn via ssh to server (not local)
How can I use via SSH something like this svn co svn+ssh://svn.mainhost.org:8890/project/trunk I need sources from svn://svn.mainhost.org:8890/project/trunk (svnserve -t with local path not have privileges) Both ssh and svn have non standard ports. For ssh I change my ~/.ssh/config but how tweak svn to use network connection instead svnserve -t ? Can't use "ssh -L" in parallel of sync (sync started from software)
Re: predecessor count for the root node-revision is wrong message
On Fri, Mar 2, 2012 at 8:12 AM, Daniel Shahaf wrote: > Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800: >> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf wrote: >> > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800: >> >> I have had a developer here create a build of the latest SVN code >> >> with your changes you mentioned in r1294470 for the svnadmin verify >> > >> > Okay, that's great news, for two reasons: >> > >> > 1. It means building svn on windows isn't as painful as it used to be :) >> >> Actually, it did take some work to get it going as we did not have >> another system available to us and also did not have VC++ 6. We had >> to use VS 2010 in order to do this. Also, for the other components >> required (python,perl etc), the files after the install were copied >> to the workstation to see if it would work as we did not want to >> change the current workstation configuration by running the >> installers. All in all, it did seem to work. >> > > Okay. The normal build requires just the *.exe and *.dll files to be > placed appropriately (such that the *.exe's and httpd's find their > libsvn_* DLL's at runtime) --- it doesn't require Administrator access, > for example. > > To clarify, Perl is only required to build OpenSSL; it is not required > to build APR, Neon, or Subversion. > >> > >> > 2. It means I can ask you to build a custom server with the 'inprocess' >> > cache disabled, or (if all else fails) to bisect, per my previous email. >> > >> > One of the things you could try is to disable caching: simply modify >> > the function create_cache() in libsvn_fs_fs/caching.c to always return >> > NULL in *CACHE_P. See below for another suggestion. >> > >> >> command. We have run 'svnadmin verify' against every revision of our >> >> hotcopy of our repository taken when we first brought this issue to >> >> the forums and are now tracking down each of the revisions to see >> >> what actions were being done at those times. >> >> >> > >> > Thanks! I do hope this work enables us to pinpoint and fix the bug. >> >> I will be going through the list to see what else was happening at the >> same time on the apache server since it was alluded to that there may >> be concurrency issues. I know the last two times that this error has >> popped up, we had two svn operations starting at around the same time >> according to the Apache logs. I will go through the previous apache >> history to see if this was always the case or not. >> > > Thanks, looking forward to hear what you come up with. > > FWIW, Justin's reply suggests that the error was seen on three different > platforms --- Windows, Solaris, and FreeBSD --- so that should narrow > down the range of possible explanations. > > (I'll also note that at ASF's installation we are not running into new > instances of the bug.) Hi Daniel. I haven't gone through all the cases yet, but I have made progress through quite a number of them and a pattern seems to be coming up. I have attached 2 txt files. One shows the modified svnadmin verify output from the binaries we built. The other shows the revisions and what appears to have been occuring at the time of the bug. I figure better to provide this now rather than delay any longer for the rest of the results. I will continue to go through the rest of the events and see if there are other differences seen when the issue occurs. I hope this information helps. Thanks. Jason SVN log history for predecessor node error: from svnadmin verify svnadmin: E160004: predecessor count for the root node-revision is wrong: r45558 has 45557, but r45557 has 45557 svnadmin: E160004: predecessor count for the root node-revision is wrong: r46947 has 46945, but r46946 has 46945 svnadmin: E160004: predecessor count for the root node-revision is wrong: r46997 has 46994, but r46996 has 46994 svnadmin: E160004: predecessor count for the root node-revision is wrong: r47004 has 47000, but r47003 has 47000 svnadmin: E160004: predecessor count for the root node-revision is wrong: r47006 has 47001, but r47005 has 47001 svnadmin: E160004: predecessor count for the root node-revision is wrong: r47193 has 47187, but r47192 has 47187 svnadmin: E160004: predecessor count for the root node-revision is wrong: r47715 has 47708, but r47714 has 47708 svnadmin: E160004: predecessor count for the root node-revision is wrong: r47718 has 47710, but r47717 has 47710 svnadmin: E160004: predecessor count for the root node-revision is wrong: r50049 has 50040, but r50048 has 50040 svnadmin: E160004: predecessor count for the root node-revision is wrong: r50963 has 50953, but r50962 has 50953 svnadmin: E160004: predecessor count for the root node-revision is wrong: r51481 has 51470, but r51480 has 51470 svnadmin: E160004: predecessor count for the root node-revision is wrong: r51684 has 51672, but r51683 has 51672 svnadmin: E160004: predecessor count for the root node-revision is wrong: r52082 has 52069, but r52081 has 52069 svnadmin:
added branch disappears?
Can anyone shed light on this issue? 1. create new branch 'foo' 2. merge different branch 'bar' into trunk 3. merge trunk into all other existing branches Seems that the branch foo disappeared sometime between 2 and 3. have the commit email showing I created the branch, so I'm dumbfounded here. Any insights would be appreciated. -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson
SVN externals (externals failed, already locked)
Hi, I've been expermenting with SVN externals and found an issue which i dont fully understand. My repository is as follows; -- +Play (with and extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "Project 3") - Project 3 (externed) -> shared.txt - Project 2 (with an extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "Outstation Files") -> -> Outstation Files (externed) -> -> -> shared.txt -> -> unieque.txt -> Project 1 (with an extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "osfiles") -> -> osfiles (externed) -> -> -> shared.txt -> -> unieque.txt - Shared Sources -> shared.txt - All the externs work as expected and changes to files in "Shared Sources" are reflected across the 3 projects. However when doing an update/checkout i get the following error " 'External failed Project 3' is allready locked via ." I suspect that its because i am external'ing not into a seperate folder, whereas in "Project 1" and "Project 2" the "Shared Sources" go in there own folder. However the externals do work as expected. I am using subversion 1.7.4 (same on server), via TortoiseSVN. regards --- Matthew J Fletcher amimjf(at)sky.com www.amimjf.org ---
RE: added branch disappears?
> Can anyone shed light on this issue? > > 1. create new branch 'foo' > 2. merge different branch 'bar' into trunk 3. merge trunk into all other > existing > branches > > Seems that the branch foo disappeared sometime between 2 and 3. have the > commit email showing I created the branch, so I'm dumbfounded here. > > Any insights would be appreciated. Did you branch to the repository or to the working copy? If you didn't commit the branch it wouldn't have gone into the repo. BOb
Re: added branch disappears?
On 03/13/2012 04:14 PM, Bob Archer wrote: Can anyone shed light on this issue? 1. create new branch 'foo' 2. merge different branch 'bar' into trunk 3. merge trunk into all other existing branches Seems that the branch foo disappeared sometime between 2 and 3. have the commit email showing I created the branch, so I'm dumbfounded here. Any insights would be appreciated. Did you branch to the repository or to the working copy? If you didn't commit the branch it wouldn't have gone into the repo. branched to the repository: svn copy svn+ssh://matrix/team/tree/app/trunk svn+ssh://matrix/team/tree/trunk/branches/819 -m 'Create a development branch' We have a commit hook, so it definitely was commited. BOb -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson
RE: added branch disappears?
> On 03/13/2012 04:14 PM, Bob Archer wrote: > >> Can anyone shed light on this issue? > >> > >> 1. create new branch 'foo' > >> 2. merge different branch 'bar' into trunk 3. merge trunk into all > >> other existing branches > >> > >> Seems that the branch foo disappeared sometime between 2 and 3. have > >> the commit email showing I created the branch, so I'm dumbfounded here. > >> > >> Any insights would be appreciated. > > > > Did you branch to the repository or to the working copy? If you didn't > > commit > the branch it wouldn't have gone into the repo. > > branched to the repository: > > svn copy svn+ssh://matrix/team/tree/app/trunk > svn+ssh://matrix/team/tree/trunk/branches/819 > -m 'Create a development branch' > > > We have a commit hook, so it definitely was commited. > > Ok, so check the log.. it's either still there or someone deleted it so it doesn't show up in HEAD. BOb
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
On Mon, Mar 12, 2012 at 1:05 PM, Simon Dean wrote: > I suspect TortoiseSVN uses the official Subversion client code under the > hood. There's no way they'd > re-implement a whole SVN client from scratch. I don't know if Tortoise uses any Subversion command line client code, but TortoiseSVN does use the official Subversion API libraries. That's what made Subversion so different from CVS. With CVS, you either had to reimplement the client yourself, or use the offical CVS client as a backend. In Subversion you write your own client, and just use the API. SVNKit is very different. SVNKit is a Java third party reimplementation of the Subversion API, and it's not the complete API either. On the other hand, the JavaHL API is a front end to the official Subversion API. So, it's possible for someone to write a Subversion client that does do a "clean up". In fact, the Jenkins Continuous build system has the option of doing a thorough clean before doing an update. > Other people have commented on the fragility of the "clean" task of a build > script. If you use things like NuGet > and Bundler in codebases, they result in multiple directories that need > "cleaning" - e.g. .\vendor\bundle, > .\packages etc. You'd be surprised how many unversioned files creep into a > CI build when all you're relying > on is the build script's "clean" task For some reason, the .NET/C# world is behind in this concept when compared to the Java world. By default, there's a "clean" target in VisualStudio builds, but it doesn't do a very good job of cleaning. However, it is still the developer's responsibility to make sure that their "clean" target cleans everything. There's a special "BeforeClean" target that's called when the "clean" target is called. You can add your own code here to clean up things that the default "clean" target doesn't do. -- David Weintraub qazw...@gmail.com
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
On Tue, 13 Mar 2012 21:14:04 +, David Weintraub wrote: ... > So, it's possible for someone to write a Subversion client that does > do a "clean up". So, what you're saying is that, because it is possible to implement 'svn cleanup' on top of the svn client libs, the official svn client won't get such a feature? (This immediately begs the question why there is an svn CLI client at all, and not just the library. ;-) ... > However, it is still the developer's responsibility to make sure that > their "clean" target cleans everything. No actually; 'make clean' is responsible to clean up everything that make produced, not 'everything', like editor backup files (or the remains of aborted merges). A 'throw out everything unversioned' VCS command comes in quite handy when - you switched branches before calling 'make clean' because now the .o file of some source existing only in one branch will be left over, - you're simply trying to get 'make clean' to actually work and don't want to iterate through the 'svn status' output each time. And 'remove; make new checkout' isn't always a valid workaround because you may want to keep local modifications of versioned files. Summary: There are a lot of reason not to implement a 'scrub the WC of unversioned files', but in my opinion "it's not our job" isn't one of them. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
