Search Results

Search found 11 results on 1 pages for 'mergeinfo'.

Page 1/1 | 1 

• How do you get subversion diff summary to ignore mergeinfo properties?

  - by tolomea

  I have subversion 1.6.5 client and 1.5.4 server. And I mostly only care about diffs on fully repository paths, not working copies. When diffing branches ones that have been merged already show up as identical except for the mergeinfo properties. This is a touch annoying for a human who has to then look through the changes looking for anything that might be a real change. However it's somewhat worse in out use case as we have scripts that run around checking on the merge state of various things and the mergeinfo properties cause them to highlight a lot of things as being out of sync when they aren't. Is there a way to get the diff summary to ignore the mergeinfo properties?

  Read the article

• Subversion - Retrieval of mergeinfo unsupported

  - by jamesthomson

  Hi, I've recently updated my Subversion package on Debian Etch to 1.5.1 via a back-port. I've gone through what I believe are all the appropriate steps but cannot for the life of me get past the following error message when I try to merge: Retrieval of mergeinfo unsupported by '.' The '.' isn't important as I get the same message whether I'm SSH'd on to the server or using TortoiseSVN through Windows. I'll take you through what I did to upgrade and test step by step: Update of Subversion Added the following line to /etc/apt/sources.list: deb http://www.backports.org/debian etch-backports main contrib non-free and then ran apt-get -s -t etch-backports install subversion Checked the version of the subversion installation Done this by running svnadmin --version and got the following output: svnadmin, version 1.5.1 (r32289) compiled Dec 11 2008, 18:10:14 Checked the client too using svn --version and got the following svn, version 1.5.1 (r32289) compiled Dec 11 2008, 18:10:14 Ok, so all looking good so far. Now I just need to upgrade the repository. After plenty of research, the most foolproof way to do this seemed to be to dump the repository and then load it again. So here's what I did: svnadmin dump /var/svn/repo > repo.dump rm -aR /var/svn/repo/* svnadmin create /var/svn/repo svnadmin load < repo.dump All that seemed to work fine. I then checked to see if the repository had been upgraded by looking at the contents of /var/svn/repo/db/format which gave: 3 layout sharded 1000 Again this indicated a Subversion 1.5 repository so all looking good. Now I try and do a merge using the Subversion client in Debian: svn mergeinfo https://mysvn/repo . and I get the following error: svn: Retrieval of mergeinfo unsupported by '.' I get the same error message whether I'm using the Debian shell on the same server or if I'm connecting via TortoiseSVN and a Windows box. If I browse to the repository using my web browser, the version number at the bottom reads: Powered by Subversion version 1.4.2 (r22196). In case it helps, the created date on mod_dav_svn.so is 2009-08-06 18:29 I just cannot figure out why I'm getting this message so any help pointing me in the right direction would be greatly appreciated. All the forum and mailing list posts that I found relating to this error were solved by doing an svnadmin upgrade, though I have actually tried that and still no joy. Thanks in advance, James.

  Read the article

• Remove unnecessary svn:mergeinfo properties

  - by LeonZandman

  When I merge stuff in my repository Subversion wants to add/change a lot of svn:mergeinfo properties to files that are totally unrelated to the things that I want to merge. Questions about this behaviour have been asked before here on Stackoverflow.com, as you can read here and here. From what I understand from the topics mentioned above it looks like a lot of files in my repository have explicit svn:mergeinfo properties on them, when they shouldn't. The advice is to reduce the amount and only put those properties on relevant files/folders. So now my question: how can I easily remove those unneeded properties? I'm using TortoiseSVN, but am reluctant to manually check/fix hundreds of files. Is there an easier way to remove those unnecessary svn:mergeinfo properties? P.S. I'm not looking for C++ SVN API code.

  Read the article

• Svn: revert file content changes without reverting any related mergeinfo?

  - by George Hawkins

  If you've done a merge you may find, before committing the changes, that actually you don't want to accept any of the changes merged into one of the affected files. So you do e.g.: $ svn revert foo.c However this also seems to revert the mergeinfo related to this file. So when you do a subsequent merge it will merge in exactly the same changes again. Rather than revert one could do: $ svn cat foo.c foo.c But this doesn't seem like the right way to do things? Is there something that more clearly indicates what I'm trying to achieve, i.e. to say "consider the merge done for this file but don't change its contents"?

  Read the article

• Tortoisesvn using svn:mergeinfo, is there a way to turn it off?

  - by Brian R. Bondy

  When I'm doing a tortoise svn merge, it includes a bunch of directories, and some files into the modified files, even know there are no actual changes. It changes the property svn:mergeinfo Is there any reason why these properties set on the directory/files are needed? Is there any way to get around not doing these changes to svn:mergeinfo? I usually just revert the items then commit, but this wastes extra time

  Read the article

• SVN supports historical merges so how is Mercurial better?

  - by radman

  Hi, I'm a long time SVN user and have been hearing a lot of brou ha ha with regard to mercurial and decentralised version control systems in general. The main touted feature that I am aware of is that merging in Mercurial is much easier because it records information for each merge so each successive merge is aware of the previous ones. Now as stated in the red book, in the section to do with merging, SVN already supports this with mergeinfo. Now I have not actually used this feature (although I wanted to, our repo version wasn't recent enough) but is this SVN feature particularly different to what Mercurial offers? For anyone who is not aware the suggested work flow for historical merging in svn is this: branch from the development trunk to do your own thing. Regularly merge changes from trunk into your branch to stay up to date. Merge back when your done with the mergeinfo to smooth the process. Without historical data merging this is a nightmare because the comparison is strictly on the differences in the files and does not take into account the steps taken on the way. So each change in the development trunk puts you further into possible conflict when you merge back. Now what I would like to know is: Does merging using Mercurial provide a significant advantage when compared with mergeinfo in SVN or is this just a lot of hot air about nothing? Has anyone used the mergeinfo feature in SVN and how good is it actually in practice?

  Read the article

• Where happens merging in SVN - on the client or server?

  - by Malcolm Frexner

  At my company we evaluate working with feature branches. We want to use mergeinfo to track merging. I have issues in some of our tested projects where merging a trunk that has only little changes into branch leads to lots of changed files because of the changed mergeinfo. I read that this behaviour improoved between version 1.5 and 1.6. Does this mean if I update the SVN - server from 1.5.6 to 1.6 I can expext some improvements when merging, or does this depend on the client (which is 1.6.11)?

  Read the article

• Detecting branch reintegration or merge in pre-commit script

  - by Shawn Chin

  Within a pre-commit script, is it possible (and if so, how) to identify commits stemming from an svn merge? svnlook changed ... shows files that have changed, but does not differentiate between merges and manual edits. Ideally, I would also like to differentiate between a standard merge and a merge --reintegrate. Background: I'm exploring the possibility of using pre-commit hooks to enforce SVN usage policies for our project. One of the policies state that some directories (such as /trunk) should not be modified directly, and changed only through the reintegration of feature branches. The pre-commit script would therefore reject all changes made to these directories apart from branch reintegrations. Any ideas? Update: I've explored the svnlook command, and the closest I've got is to detect and parse changes to the svn:mergeinfo property of the directory. This approach has some drawback: svnlook can flag up a change in properties, but not which property was changed. (a diff with the proplist of the previous revision is required) By inspecting changes in svn:mergeinfo, it is possible to detect that svn merge was run. However, there is no way to determine if the commits are purely a result of the merge. Changes manually made after the merge will go undetected. (related post: Diff transaction tree against another path/revision)

  Read the article

• SVN tool to rebase a branch in git style

  - by timmow

  Are there any tools available that will let me rebase in git style an SVN branch onto a new parent? So, in the following situation, I create a feature branch, and there are commits to the trunk E---F---G Feature / A---B---C---D--H--I trunk I'm looking for a tool which copies the trunk, and applies the commits one by one, letting me resolve any conflicts if any exist - but each commit retains the same commit message, and is still a separate commit. E'---F'---G' Feature / A---B---C---D--H--I trunk So commit E' will be a commit with the same changes as E, except in the case of E causing a conflict, in which case E' will differ from E in that E' has the conflicts resolved, and the same commit message as E. I'm looking for this as it helps in keeping branches up to date with trunk - the svnmerge.py / mergeinfo way does not help, as you still need to resolve your changes when you merge back to trunk.

  Read the article

• installing SVN - CentOS - cannot find -lexpat

  - by furnace

  Hey guys, I'm trying to install SVN on CentOS 5. Unfortunately a simple yum install isn't going to work (afaik) because I'm using the DirectAdmin control panel. When it comes to running 'make' I get this error: /usr/bin/ld: cannot find -lexpat I'm new to installing things without yum (!) so am a bit lost. Do you have any advice on how to get past this hurdle? Just to give a little more context to the error; /apache -I/usr/include/apache -I/etc/svn-install/subversion-1.6.2/sqlite-amalgamation -o subversion/svn/util.o -c subversion/svn/util.c cd subversion/svn && /bin/sh /etc/svn-install/subversion-1.6.2/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -pthread -rpath /usr/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o changelist-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o conflict-callbacks.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o main.o merge-cmd.o mergeinfo-cmd.o mkdir-cmd.o move-cmd.o notify.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolve-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o tree-conflicts.o unlock-cmd.o update-cmd.o util.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /etc/httpd/lib/libaprutil-1.la -lexpat /etc/httpd/lib/libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl /usr/bin/ld: cannot find -lexpat collect2: ld returned 1 exit status make: *** [subversion/svn/svn] Error 1 Thanks!

  Read the article

• Compile subversion on CentOs

  - by peter

  I have downloaded, compiled and installed so far: apr-1.3.9 apr-util-1.3.9 sqlite-3.6.23 zlib-1.2.4 libtool-2.2.6b Now after downloading subversion-1.6.9, the config works fine but compiling it will end with the following error: cd subversion/svn && /bin/sh /root/subversion-1.6.9/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -pthread -rpath /usr/local/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o changelist-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o conflict-callbacks.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o main.o merge-cmd.o mergeinfo-cmd.o mkdir-cmd.o move-cmd.o notify.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolve-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o tree-conflicts.o unlock-cmd.o update-cmd.o util.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/apr/lib/libaprutil-1.la -lexpat /usr/local/apr/lib/libapr-1.la -lrt -lcrypt -lpthread -ldl /usr/bin/ld: cannot find -lexpat collect2: ld returned 1 exit status make: * [subversion/svn/svn] Error 1 The file at /usr/local/apr/lib/libapr-1.la exists and seems to be OK (from permission perspective What could be the problem here? Thanks Peter

  Read the article

1