Re: Unexpected behavior during mergeinfo elision scenario
On Mon, Mar 26, 2012 at 03:15:17PM -0500, John wrote: > $ svn merge --record-only ^/myproject/trunk/subdir@2676 subdir > > $ svn pg 'svn:mergeinfo' subdir > subdir - /myproject/branches/W/subdir:1488-2675 > /myproject/branches/Y/subdir:5925-7118 > /myproject/trunk/subdir:1488-7532 > > $ svn pg 'svn:mergeinfo' subdir/A > (At this point the merginfo on subdir/A has been elided.) Great! > I'm now seeing the desired elision behavior, but I do not fully understand > why using "--record-only" changed the behavior so dramatically. > Without the "--record-only" flag, nothing was modified. > e.g. > $ svn merge -q ^/myproject/trunk/subdir@2780 subdir > $ svn diff > [no output from svn diff] > > Shouldn't the changes to "svn:mergeinfo" be the same, > regardless of whether or not "--record-only" is used? I think this happens because there are no operative revisions for 'subdir' in the range being merged. As of the 1.7 release, Subversion no longer creates mergeinfo changes for unaffected subtrees during merges. See http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording However, this behaviour wasn't implemented for record-only merges. Record-only merges still update all subtree mergeinfo within the merge target. I don't know why record-only merges behave differently. Perhaps the new behaviour is too difficult to implement for record-only merges, or maybe this difference exists on purpose.
Re: Subversion 1.7 server & client issue : not able to commit E160013 path not found
Philip Martin writes: > vishwajeet singh writes: > >> As thread it's not just with mod_wsgi, problem persist with fcgi, can you >> please elaborate on reordering I tried moving wsgi module at end but that >> did not help. > > Reordering may not work; it depends how the other modules work. Fixing > it may require code changes in the non-Subversion modules. The error > message: > > svn: E160013: '/svn/RDR/!svn/me' path not found > > is exactly what happens when some other module intercepts POST requests > intended for mod_dav_svn. I've just added mod_wsgi 3.3-2 to my test environment and Subversion's v2 protocol still works. This is a Subversion commit over v2: ::1 - - [27/Mar/2012:12:04:18 +0100] "OPTIONS /obj/repo HTTP/1.1" 200 188 ::1 - - [27/Mar/2012:12:04:18 +0100] "POST /obj/repo/!svn/me HTTP/1.1" 201 - ::1 - - [27/Mar/2012:12:04:18 +0100] "PROPPATCH /obj/repo/!svn/txn/16-h HTTP/1.1" 207 426 ::1 - - [27/Mar/2012:12:04:18 +0100] "MKCOL /obj/repo/!svn/txr/16-h/A HTTP/1.1" 201 199 ::1 - - [27/Mar/2012:12:04:18 +0100] "MERGE /obj/repo HTTP/1.1" 200 424 This is mod_wsgi request: ::1 - - [27/Mar/2012:12:04:22 +0100] "GET /myapp HTTP/1.1" 200 12 I used a very basic mod_wsgi configuration, just a line: WSGIScriptAlias /myapp /home/pm/sw/subversion/obj/myapp.wsgi I suggest you setup a test environment with a working Subversion config. Gradually extend it with mod_wsgi until it stops working. Then tell us, and/or the mod_wsgi people, which config change causes Subversion to fail. -- Philip
Re: Subversion 1.7 server & client issue : not able to commit E160013 path not found
On Mon, Mar 26, 2012 at 5:43 AM, vishwajeet singh wrote: > Hi All, > > I recently upgraded from subversion server from 1.6 to 1.7, everything > works fine for 1.6 client and 1.7 server. > But when I upgrade to 1.7 client my commit fails with following error > > *svn: E160013: Commit failed (details follow):* > *svn: E160013: '/svn/RDR/!svn/me' path not found* > > I am able to checkout and update with 1.7 client but not able to commit. > > My apache version is 2.3 and OS is centos 5.4. > > Backup your system first. Second, you're running CentOS 5.4 (5.8 is out) and HTTPD 2.3. (The official name is now HTTPD, not Apache, and RHEL published 2.2.15, not 2.3, their version 5 operating system.) So you're working with hand-built Apache, and may be working with hand-built Subversion. This way lies integration madness. Where did you get each component? The Subversion RPM's at Repoforge were updated by me to 1.7.3, but you'll probably want to compile them with a clean HTTPD SRPM and RPM's to get the libraries cleanly consistent. Third: serously consider upgrading to CentOS or Scientific Linux 6.x. You'll be in much better shape for running modern versions of powerful, constantly upgrading tools like current Subversion releases, rather than trying to debug old and hand-built systems. > Any help in this regard is appreciated > > Regards, > Vishwajeet Singh > +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com > Twitter: http://twitter.com/vishwajeets | LinkedIn: > http://www.linkedin.com/in/singhvishwajeet >
Understanding PySvn – Where to start from?
In need to understand what PySvn is all about (so to compare it with Slik-Subversion I'm currently using), downloaded and installed py27-pysvn-svn173-1.7.6-1457.exe and pysvn-workbench-svn173-1.6.6-1460.exe, I haven't got a clue what to do next. Of course I'm badly in need of some initial break-ice support. Could any good soul be so kind to be of help? Gratefully, yours - P.M.
Re: Understanding PySvn – Where to start from?
On Tue, Mar 27, 2012 at 8:33 PM, Pietro Moras wrote: > In need to understand what PySvn is all about (so to compare it with > Slik-Subversion I'm currently using), downloaded and installed > py27-pysvn-svn173-1.7.6-1457.exe and pysvn-workbench-svn173-1.6.6-1460.exe, > I haven't got a clue what to do next. > pysvn is alternative python binding for Subversion whereas slik svn is a subversion client, people here can you help better if you can tell what are you trying to do ?? > Of course I'm badly in need of some initial break-ice support. Could any > good soul be so kind to be of help? > > Gratefully, yours > > - P.M. > -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Re: Understanding PySvn – Where to start from?
On Tue, Mar 27, 2012 at 11:03 AM, Pietro Moras wrote: > In need to understand what PySvn is all about (so to compare it with > Slik-Subversion I'm currently using), downloaded and installed > py27-pysvn-svn173-1.7.6-1457.exe and pysvn-workbench-svn173-1.6.6-1460.exe, > I haven't got a clue what to do next. > > Of course I'm badly in need of some initial break-ice support. Could any > good soul be so kind to be of help? There is no comparison. SlikSVN is the Subversion command line binaries compiled for Windows. There are many such distributions available, they are all identical except for the packaging. PySVN is a library that exposes the Subversion API as a Python API so that you can write code that uses the Subversion API using Python. The Python Workbench is a Python GUI client written by the author of PySVN that uses PySVN to implement the calls to the SVN API. You could compare the Python Workbench to other GUI SVN clients if you wanted, such as TortoiseSVN. -- Thanks Mark Phippard http://markphip.blogspot.com/
Issue with svn log --diff option
Hello, I have used "svn log --diff path/to/myfile.txt" but the command generates history from the current working directory instead of limiting the report to the provided path. Is it the expected behavior ? If not please create an issue in tracker. -- Yves Martin
RE: Which is the most used/best Windows Subversion distribution?
> When I go to the download page for the Subversion binaries for WindowsOS: > > http://subversion.apache.org/packages.html > > Then there are 5 different packages: > > CollabNet (supported and certified by CollabNet; requires registration) > SlikSVN > (32- and 64-bit client MSI; maintained by Bert Huijben, SharpSvn project) > VisualSVN (client and server; supported and maintained by VisualSVN) > WANdisco (32- and 64-bit client and server; supported and certified by > WANdisco) Win32Svn (32-bit client, server and bindings, MSI and ZIPs; > maintained by David Darj) > > > What are the differences between them? > > Which one is the "best supported"/most compatible? > > Which one is the most widely used in WinOS world? > > Thank you > Ben No "free" version is supported so to speak. IF you are looking for a client install for Windows I suggest TortoiseSVN. It include the Shell UI and also includes the svn command line exe. BOb
RE: Understanding PySvn – Where to start from?
Dear Vishwajeet, Thanks for your kind & quick answer. > better if you can tell what are you trying to do Well, what I have got to do is simply to understand. Therefore, for instance, you could describe me how you are possibly using PySvn and/or WorkBench. I mean: not in detail, just in general terms. So to offer me an idea how I could myself conveniently use and test it. Thanks.See you. - P.M.
RE: Understanding PySvn – Where to start from?
Dear Mark, -- PySvn as a Python API, clear enough. -- Now I'd expect that WorkBench would be a ready-to-use (Windows?) program. But, so far, I haven't been able to run it, nor to find any practical documentation clearly describing what it is. What am I missing? Something very primordial, I fear... Thanks. See you. - P.M. P.S. You said: > such as TortoiseSVN By the way, among some books recently received, I've spotted one about TortoiseSVN 1.7. Could it be of help starting from such book?
Re: Understanding PySvn – Where to start from?
On Tue, Mar 27, 2012 at 12:31 PM, Pietro Moras wrote: > Dear Mark, > -- PySvn as a Python API, clear enough. > -- Now I'd expect that WorkBench would be a ready-to-use (Windows?) > program. But, so far, I haven't been able to run it, nor to find any > practical documentation clearly describing what it is. > What am I missing? Something very primordial, I fear... Thanks. I have never used it, so cannot say. >> such as TortoiseSVN > By the way, among some books recently received, I've spotted one about > TortoiseSVN 1.7. Could it be of help starting from such book? If you are on Windows you should install TortoiseSVN (and the command line client). I am not saying that is the only client to use, but you should install it. I do most work in Eclipse, so I use Subclipse but I still use TortoiseSVN and the command line client too. The beauty of SVN is that you can mix all these clients on the same code provided they are all the same major.minor version. If this Python Workbench looks like a nice client to you, then use that too. I would try their mailing lists for help on getting it to run. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Issue with svn log --diff option
On Tue, Mar 27, 2012 at 05:58:58PM +0200, Yves Martin wrote: > Hello, > > I have used "svn log --diff path/to/myfile.txt" > but the command generates history from the current working directory > instead of limiting the report to the provided path. > > Is it the expected behavior ? If not please create an issue in tracker. Depends on which version of svn you are using. There was a bug in log --diff with moved nodes which was fixed in 1.7.4. Another problem was that if the file was newly added the diff used to be anchored at its parent: http://subversion.tigris.org/issues/show_bug.cgi?id=2873 This was fixed in 1.7.2. Does either of these fixes apply to your situation? In any case, if you're not using Subversion 1.7.4, can you please try to reproduce the problem you are seeing with 1.7.4? If you can reproduce it with 1.7.4, can you please try to provide an example 'svn log' invocation against a public Subversion repository (for instance, http://svn.apache.org/repos/asf) that shows the problem? Please also read this thread on the dev@ list in case it applies to your problem: http://svn.haxx.se/dev/archive-2012-03/0385.shtml Thanks.
