Merging Properties?
Hello, Suppose I have a file on trunk called file.txt. I put a property on it, say color with the value red. Now I copy trunk to a branch B. On branch B I change file.txt's color property to green. Now independently on trunk, I also change file.txt's color property to green. When I merge the branch B back to trunk, I get a merge conflict, even though both the branch and the trunk are trying to change the property to the same value. Is this expected or a bug or ...? I'm using TortoiseSVN 1.6.15 on Windows which I think is using Subversion 1.6.16. Thanks. BN
Re: Merging Properties?
On Fri, Jun 10, 2011 at 4:28 AM, Stefan Sperling wrote: > On Fri, Jun 10, 2011 at 11:25:23AM +0200, Stefan Sperling wrote: >> On Fri, Jun 10, 2011 at 11:16:44AM +0200, Johan Corveleyn wrote: >> > On Fri, Jun 10, 2011 at 11:07 AM, Stefan Sperling wrote: >> > >> > ... >> > > svn ps color green $branch/alpha >> > > svn commit $trunk -m "set color to green" >> > >> > Shouldn't the above be 'svn commit $branch ...'? >> >> Ooops, you're right, thanks for catching that! >> Yeah, with this change the script does indeed cause a spurious conflict, >> even in 1.7. > > Filed http://subversion.tigris.org/issues/show_bug.cgi?id=3919 > Thank you Stefan for reproducing the issue with the script and reporting it as a bug. I'd be willing to try to work up a patch or help resolve the bug in any way. Just give me a bit of a nudge in the right direction. Best regards, BN
Problem with Python bindings to SVN 1.7.4 on Windows
Hello -
I'm trying to upgrade a Subversion and Trac install running on Windows
Server 2003 sp2.
I've installed Subversion 1.7.4 from the .msi file found here:
http://sourceforge.net/projects/win32svn/files/1.7.4/
I'm also using the Python 2.7 bindings found in that same directory
(svn-win32-1.7.4_py27.zip).
I've unzipped the Python binding into C:\Python27\Lib\site-packages.
Trac isn't able to load the bindings.
Here is a troubleshooting step and the output:
E:\Trac_Data>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from svn import client
Traceback (most recent call last):
File "", line 1, in
File "C:\Python27\lib\site-packages\svn\client.py", line 26, in
from libsvn.client import *
File "C:\Python27\lib\site-packages\libsvn\client.py", line 25, in
_client = swig_import_helper()
File "C:\Python27\lib\site-packages\libsvn\client.py", line 21, in swig_import
_helper
_mod = imp.load_module('_client', fp, pathname, description)
ImportError: DLL load failed: The operating system cannot run %1
Does anyone have any ideas? I noticed there are no DLL files in the
libsvn folder in the bindings. In the past, with older versions of
Subversion, I've had to rename the libsvn/*.dll files to *.pyd to get
stuff to work. Now there is just *.pyd files in libsvn.
Thank you,
BN
Re: Problem with Python bindings to SVN 1.7.4 on Windows
On Wed, Mar 21, 2012 at 11:12 AM, Brian Neal wrote:
[... snip ..]
> Hello -
>
> I'm trying to upgrade a Subversion and Trac install running on Windows
> Server 2003 sp2.
>
> I've installed Subversion 1.7.4 from the .msi file found here:
> http://sourceforge.net/projects/win32svn/files/1.7.4/
>
> I'm also using the Python 2.7 bindings found in that same directory
> (svn-win32-1.7.4_py27.zip).
>
> I've unzipped the Python binding into C:\Python27\Lib\site-packages.
>
> Trac isn't able to load the bindings.
>
[... snip ...]
> _mod = imp.load_module('_client', fp, pathname, description)
> ImportError: DLL load failed: The operating system cannot run %1
I have solved my problem by copying libeay32.dll and ssleay32.dll from
the Subversion\bin folder to C:\Python27\Lib\site-packages\libsvn
folder. I got this tip via a google search on the Trac users list. I
don't understand this, but thought I would follow-up here on this list
in case it helps other poor dopes who have to run on Windows.
-BN
Re: Problem with Python bindings to SVN 1.7.4 on Windows
On Wed, Mar 21, 2012 at 12:10 PM, Cooke, Mark wrote: >> >> On Wed, Mar 21, 2012 at 11:12 AM, Brian Neal wrote: >> >> I have solved my problem by copying libeay32.dll and ssleay32.dll from >> the Subversion\bin folder to C:\Python27\Lib\site-packages\libsvn >> folder. I got this tip via a google search on the Trac users list. I >> don't understand this, but thought I would follow-up here on this list >> in case it helps other poor dopes who have to run on Windows. >> >> -BN >> > Thinking about this, I have the subversion bin folder in my path, I suspect > that it is not in yours? I assume therefore you probably use TortoiseSVN > (and why not) which does not (AFAIK) need svn in the path so does not add > it... > > ~ mark c I'm doing all this work on the server side. Yes, C:\Program Files\Subversion\bin is on the path. It is needed for Apache to find the SVN binaries. It is strange that I also need to copy those 2 DLL's to the Python bindings folder. Thanks, BN
Re: Problem with Python bindings to SVN 1.7.4 on Windows
On Wed, Mar 21, 2012 at 1:41 PM, Alagazam.net Subversion wrote: > > Do you have another libeay32.dll and ssleay32.dll in some other folder that > is before Subversion\bin in your path ? > If that's the case and these are older versions there might be trouble. > > /David a.k.a. Alagazam > Why yes, those DLL's do exist in an earlier folder on the path! Is there anything that can be done to avoid a problem like that in the future? Perhaps a note in the readme? I have noticed that Bitnami and Collabnet dump all the SVN and Python binding DLL's into the same folder. I'm not a windows / dll expert so I don't know if that is a good solution or not. Thanks for the help. And thanks very much for making those Windows binaries available. -BN
Re: getversion.py invalid syntax
The syntax except IOError, e: is perfectly valid in Python 2.7. Are you sure you are getting that particular error under 2.7? You'd have to change it to this for Python 3.x: except IOError as e: But that would not be backwards compatible with 2.x. Using a tool like 2to3.py may help produce a version of the script that could run under Python 3.x. Best, BN
Corrupt working copy after merge cancel - SVN 1.7.4
Hello - We are using SVN 1.7.4 and TortoiseSVN 1.7.6 on Windows. My colleague was doing a merge and hit cancel. His working copy now appears to be corrupted. All operations fail with a message that cleanup is needed. Trying to run cleanup at the top level folder results in Tortoise putting up an error dialog that says: "Cleanup failed to process the following paths: D:\Project_Files\BlackCoS Can't open file 'C:\WINDOWS\TEMP\svn-D4AA62C8'. The system cannot find the file specified." Luckily he has no outstanding changes and can make a new working copy. But if you have any suggestions on how to un-wedge it, or if we can do any trouble-shooting for you if this is a bug, please let me know. Thanks, BN
Re: Corrupt working copy after merge cancel - SVN 1.7.4
Hello Thorsten, > C:\Windows\Temp is no default temporary directory for a user. Normally > Subversion would use the user specific Temp directory, unless you > configured your user to use Windows\Temp, which is not recommended at > all. I would guess that your environment may be a little bit special > and therefore you should describe it and maybe ran into permission > problems in Windows\Temp. I believe you have hit on something. We use an embedded compiler tool chain on Windows XP that is somewhat old, and it sometimes errors out when it encounters spaces in path names. I don't think I have encountered this problem, but my colleague and a few others have. Therefore they have explicitly set the environment variable TEMP, and in this particular case, my colleague has TEMP=C:\Windows\Temp. Taking a poll around the office, others have set it to TEMP=C:\Temp. Mine is still the default, which I believe is TEMP=C:\DOCUME~1\brian\LOCALS~1\Temp. So now we are left a bit puzzled as to why some of us have encountered the "spaces in path" problem with the compiler and others have not. But that isn't a concern for this list. :) But in any event, I will advise my colleague to change the value of his TEMP variable if you think C:\Windows\Temp can cause a permissions problem for Subversion. Just for completeness, to answer to your questions (which may not be relevant now): > For example is the Working Copy user specific or system wide? I am not sure I know what you mean. It is a "normal" working copy created interactively by an XP user using Tortoise. I didn't know you could create "system wide" or "user specific" working copies. > Was the merging user really a normal user or "something" in a service context? Normal, interactive user sitting at a keyboard. :) Thank you! Regards, BN
Re: Corrupt working copy after merge cancel - SVN 1.7.4
I just did some more testing. I tried to recreate my colleagues problem by creating a working copy, doing a merge, then cancelling it. I was unable to reproduce the problem in any event. I used both my values for TEMP and I also used his (C:\Windows\Temp). Thanks, BN 2012/4/6 Brian Neal : > Hello Thorsten, > >> C:\Windows\Temp is no default temporary directory for a user. Normally >> Subversion would use the user specific Temp directory, unless you >> configured your user to use Windows\Temp, which is not recommended at >> all. I would guess that your environment may be a little bit special >> and therefore you should describe it and maybe ran into permission >> problems in Windows\Temp. > > I believe you have hit on something. We use an embedded compiler tool > chain on Windows XP that is somewhat old, and it sometimes errors out > when it encounters spaces in path names. I don't think I have > encountered this problem, but my colleague and a few others have. > Therefore they have explicitly set the environment variable TEMP, and > in this particular case, my colleague has TEMP=C:\Windows\Temp. Taking > a poll around the office, others have set it to TEMP=C:\Temp. Mine is > still the default, which I believe is > TEMP=C:\DOCUME~1\brian\LOCALS~1\Temp. > > So now we are left a bit puzzled as to why some of us have encountered > the "spaces in path" problem with the compiler and others have not. > But that isn't a concern for this list. :) But in any event, I will > advise my colleague to change the value of his TEMP variable if you > think C:\Windows\Temp can cause a permissions problem for Subversion. > > Just for completeness, to answer to your questions (which may not be > relevant now): > >> For example is the Working Copy user specific or system wide? > > I am not sure I know what you mean. It is a "normal" working copy > created interactively by an XP user using Tortoise. I didn't know you > could create "system wide" or "user specific" working copies. > >> Was the merging user really a normal user or "something" in a service >> context? > > Normal, interactive user sitting at a keyboard. :) > > Thank you! > > Regards, > BN
Re: Corrupt working copy after merge cancel - SVN 1.7.4
I'll keep the working copy around in case anyone wants us to troubleshoot it somehow. I don't know if you can interrogate the sqlite database or metadata somehow and see why it is "stuck". Again, we can't seem to reproduce the problem. Thanks, BN
Reintegrate merging with sparse checkouts
Hello - My question is basically the same as this one: http://svn.haxx.se/users/archive-2010-04/0097.shtml We are forced to use an unwieldy and inconvenient directory structure. Spare checkouts are a big help to us. But it seems that (in the few times I have tried) to reintegrate a feature branch to trunk it has failed if either of the working copies are sparse. I believe I understand why this is; when you merge from trunk to your branch, the merge info cannot get applied to the directories you have omitted from your branch working copy. And when you finally go to reintegrate your branch back to trunk, the reintegrate fails because SVN sees you have not applied all the changes to certain directories. Perhaps I have done this wrong. If I have the same sparse directory structures in my trunk & branch working copies (i.e. I made them sparse in exactly the same way), should the reintegrate merge work? Otherwise is there a way to tell SVN that the directories I omitted from my working copies are irrelevant and do not need to be merged? Thank you, BN
Re: Reintegrate merging with sparse checkouts
On Mon, May 21, 2012 at 9:01 AM, Johan Corveleyn wrote: > [ Redirecting back to the list -- please always use "reply all" to > keep the discussion on the list. More below ... ] Sorry about that... see below. > > On Mon, May 21, 2012 at 3:54 PM, Brian Neal wrote: >> On Mon, May 21, 2012 at 5:15 AM, Johan Corveleyn wrote: >>> On Fri, May 18, 2012 at 9:48 PM, Brian Neal wrote: >>>> Hello - >>>> >>>> My question is basically the same as this one: >>>> >>>> http://svn.haxx.se/users/archive-2010-04/0097.shtml >>>> >>>> We are forced to use an unwieldy and inconvenient directory structure. >>>> Spare checkouts are a big help to us. But it seems that (in the few >>>> times I have tried) to reintegrate a feature branch to trunk it has >>>> failed if either of the working copies are sparse. I believe I >>>> understand why this is; when you merge from trunk to your branch, the >>>> merge info cannot get applied to the directories you have omitted from >>>> your branch working copy. And when you finally go to reintegrate your >>>> branch back to trunk, the reintegrate fails because SVN sees you have >>>> not applied all the changes to certain directories. >>>> >>>> Perhaps I have done this wrong. If I have the same sparse directory >>>> structures in my trunk & branch working copies (i.e. I made them >>>> sparse in exactly the same way), should the reintegrate merge work? >>>> >>>> Otherwise is there a way to tell SVN that the directories I omitted >>>> from my working copies are irrelevant and do not need to be merged? >>> >>> Which version of svn did you use (client-side)? What do you mean by >>> "failed"? >> >> SVN 1.7.4. >> >> "Failed" as in the reintegrate merge back to trunk was prevented from >> happening. I regret not writing down the error message, but the gist >> of it was SVN could not find merge info on the directories I did not >> have in my sparse working copies. To work around it, we either have to >> reintegrate merge sub-directories multiple times, or just remove the >> --reintegrate flag and deal with the less than ideal results (tree >> conflicts). >> >> When I get some time I will try to come up with a toy example that >> reproduces the issue. > > Yes, that would be very useful. I was able to reproduce the issue, please see the attached sparse-merge.txt and I captured the output and error that I see in the attached file out.txt. (Note that I had to rename sparse-merge.bat to sparse-merge.txt before Gmail would send it). I am using SVN 1.7.4 on Windows XP. The high level description of what is going on in the script is: 1. Create a repo using your sample greek tree. 2. Make a sparse working copy of trunk, omitting the A\B directory (trunk_wc) 3. Copy trunk to a feature branch. 4. Make a sparse working copy of the feature branch (omitting A\B -- branch_wc) 5. Make a full working copy of trunk (trunk_b_wc). 6. Now change files in all three working copies and commit (but don't create conflicts). In particular, in trunk_b_wc, change a file under A\B. 7. Merge trunk to the feature branch. 8. Reintegrate merge the feature branch back to trunk. 9. Observe that the merge fails, presumably because the changes to A\B never made it to the feature branch. Thanks for your time and consideration. -BN Base url for repo: file:///C:/Project_Files/svn_tests/sparse_merge/repos Making a Greek Tree for import... Importing it... Checking out a sparse working copy (omitting the A\B directory).. Atrunk_wc\A Atrunk_wc\iota Checked out revision 1. Updating 'trunk_wc\A\C': Atrunk_wc\A\C Updated to revision 1. Updating 'trunk_wc\A\D': Atrunk_wc\A\D Atrunk_wc\A\D\gamma Atrunk_wc\A\D\G Atrunk_wc\A\D\G\pi Atrunk_wc\A\D\G\rho Atrunk_wc\A\D\G\tau Atrunk_wc\A\D\H Atrunk_wc\A\D\H\chi Atrunk_wc\A\D\H\omega Atrunk_wc\A\D\H\psi Updated to revision 1. Making a branch of trunk called 'feature'... Committed revision 2. Making a working copy of the feature branch... Abranch_wc\A Abranch_wc\iota Checked out revision 2. Updating 'branch_wc\A\C': Abranch_wc\A\C Updated to revision 2. Updating 'branch_wc\A\D': Abranch_wc\A\D Abranch_wc\A\D\gamma Abranch_wc\A\D\G Abranch_wc\A\D\G\pi Abranch_wc\A\D\G\rho Abranch_wc\A\D\G\tau Abranch_wc\A\D\H Abranch_wc\A\D\H\chi Abranch_wc\A\D\H\omega Abranch_wc\A\D\H\psi Updated to revision 2. Make a full working copy of trunk for fiddling with B... Atrunk_b_wc\A Atrunk_b_wc\A\B Atrunk_b_wc\A\B\l
Re: Reintegrate merging with sparse checkouts
On Tue, May 22, 2012 at 7:31 AM, Johan Corveleyn wrote: > On Mon, May 21, 2012 at 9:00 PM, Brian Neal wrote: > [ ... ] >> I was able to reproduce the issue, please see the attached >> sparse-merge.txt and I captured the output and error that I see in the >> attached file out.txt. (Note that I had to rename sparse-merge.bat to >> sparse-merge.txt before Gmail would send it). >> >> I am using SVN 1.7.4 on Windows XP. >> >> The high level description of what is going on in the script is: >> >> 1. Create a repo using your sample greek tree. >> 2. Make a sparse working copy of trunk, omitting the A\B directory (trunk_wc) >> 3. Copy trunk to a feature branch. >> 4. Make a sparse working copy of the feature branch (omitting A\B -- >> branch_wc) >> 5. Make a full working copy of trunk (trunk_b_wc). >> 6. Now change files in all three working copies and commit (but don't >> create conflicts). In particular, in trunk_b_wc, change a file under >> A\B. >> 7. Merge trunk to the feature branch. >> 8. Reintegrate merge the feature branch back to trunk. >> 9. Observe that the merge fails, presumably because the changes to A\B >> never made it to the feature branch. > > Ah ok, I see. It fails with: > > svn: E195016: Reintegrate can only be used if revisions 2 through 6 > were previously merged from file:///C:/Temp/svn-test > /repos/trunk to the reintegrate source, but this is not the case: > branches/feature/A > Missing ranges: /trunk/A:4 > > where revision 4 is the revision on trunk which affected A\B, which > was missing (excluded by sparseness) from the branch-wc which you used > to do the sync merge. > > I believe that this is normal behavior then, with the current > functionality of svn: revision 4 is indeed not synced, and the branch > must be synced completely (there must not be any gaps) for it to be > reintegratable. > > OTOH, you could argue that --reintegrate should just work in this > case, similar to the normal sync merge, by only looking at the parts > that are present in the working copy (and using non-inheritable > mergeinfo to mark the parts where the (reintegrate) merge was not > performed in full). Hmmm, otherwise you'd almost always need full > working copies to perform the merges, even if you're fine with only > merging (and reintegrating) some parts ... > > I'm not really an expert on the merge logic and tracking, but I think > this would be a useful enhancement (unless someone contradicts me > here). So I'd say: please file an issue. I have filed issue #4187: http://subversion.tigris.org/issues/show_bug.cgi?id=4187 Thanks for looking the issue over Johan. Regards, -BN
