Lost work due to non-cummutative merges
Hi, we have the following situation: 1. A branch is created from trunk. 2. In trunk a line of code is added and commited as revision X 3. The line is removed again and commited as revision X+1 4. In branch changeset X+1 is merged from trunk 5. In branch changeset X is merged from trunk. The problem is now that in the branch the line is still there and one gets no warning from subversion that something is wrong. Is this a bug in subversion? Why isn't there at least a merge conflict for step 4? Christoph
Re: Properties lost on checkin
Am 21.05.2011 19:12, schrieb Daniel Shahaf: Does http://subversion.tigris.org/issues/show_bug.cgi?id=3884 describe the problem you were seeing? Yes. But I wonder why file sees a text file for you. In the repository where I do the merge I see a symlink. I get a normal file only after a new checkout or update. Christoph
Re: Properties lost on checkin
Hi,
do I have to open an issue for this?
Am 17.05.2011 13:24, schrieb Daniel Shahaf:
I committed
http://svn.apache.org/viewvc?view=rev&revision=r1104092
before I saw this mail from you.
(please add dev@ to CC if needed)
Christoph Bartoschek wrote on Tue, May 17, 2011 at 11:06:47 +0200:
Hi,
I have a small script that reproduces the problem:
dir=$PWD
svnadmin create a
svnadmin create b
svn co file://${dir}/a ca1
svn co file://${dir}/b cb1
cd ${dir}/ca1
touch file
svn add file
svn ci -m "Added file"
ln -sf file link
svn add link
svn ci -m "Added link"
cd ${dir}/cb1
svn merge -r 0:1 file://${dir}/a .
svn ci -m "Merged revision 1"
svn up
svn merge -r 1:2 file://${dir}/a .
svn ci -m "Merged revision 2"
cd ${dir}
svn co file://${dir}/b cb2
ls -l cb1
ls -l cb2
Am 17.05.2011 12:00, schrieb Daniel Shahaf:
CC += dev@
I haven't tried with 1.6.x, but merging a symlink-add from a foreign
repository does result in bogus state with current trunk:
[[[
% $svn merge -c r922451
https://svn.apache.org/repos/asf/subversion/site/publish/
--- Merging (from foreign repository) r922451 into '.':
Afaq.en.html
% $svn st
~M faq.en.html
% $svn info faq.en.html
Path: faq.en.html
Name: faq.en.html
Working Copy Root Path: /tmp/svn/wc1
URL: file:///tmp/svn/r1/trunk/faq.en.html
Repository Root: file:///tmp/svn/r1
Repository UUID: 0d8f1070-806c-11e0-a89b-a382cea1935c
Node Kind: file
Schedule: add
% file faq.en.html
faq.en.html: ASCII text, with no line terminators
%
]]]
I'll forward this to dev@ (CC'ing you).
Christoph Bartoschek wrote on Tue, May 17, 2011 at 09:24:30 +0200:
Hi,
I have a workarea where I merged in some changes from a completely
different repository. One of the changes was the creation of a link.
After checking in I see that the link is ok in my workarea but not in
any other workarea.
This due to the missing svn:special keyword that was not checked in. How
can this happen?
The following shows inconsistent behaviour in my opinion. How can this
be explained:
esquad$ svn proplist -v tm.h
Properties on 'tm.h':
svn:special
*
esquad$ svn info tm.h
Path: tm.h
Name: tm.h
URL: https://server/trunk/include/tm/tm.h
Repository Root: https://server
Repository UUID: 608964b8-1798-474c-b2d9-552667dc04a5
Revision: 27
Node Kind: file
Schedule: normal
Last Changed Author: christoph
Last Changed Rev: 26
Last Changed Date: 2011-05-16 18:11:17 -0400 (Mon, 16 May 2011)
Text Last Updated: 2011-05-17 02:51:09 -0400 (Tue, 17 May 2011)
Checksum: 1a7ff762ceabb28ca8865f9b0ba377ff
esquad$ svn proplist -v https://server/trunk/include/tm/tm.h
esquad$ svn diff -r HEAD tm.h
This shows that locally the svn:special keyword is set but not on the
server. But svn does not see any difference. Is this a known bug? Or
how can I get the missing keywords checked in?
Christoph
Re: Properties lost on checkin
Hi,
I have a small script that reproduces the problem:
dir=$PWD
svnadmin create a
svnadmin create b
svn co file://${dir}/a ca1
svn co file://${dir}/b cb1
cd ${dir}/ca1
touch file
svn add file
svn ci -m "Added file"
ln -sf file link
svn add link
svn ci -m "Added link"
cd ${dir}/cb1
svn merge -r 0:1 file://${dir}/a .
svn ci -m "Merged revision 1"
svn up
svn merge -r 1:2 file://${dir}/a .
svn ci -m "Merged revision 2"
cd ${dir}
svn co file://${dir}/b cb2
ls -l cb1
ls -l cb2
Am 17.05.2011 12:00, schrieb Daniel Shahaf:
CC += dev@
I haven't tried with 1.6.x, but merging a symlink-add from a foreign
repository does result in bogus state with current trunk:
[[[
% $svn merge -c r922451
https://svn.apache.org/repos/asf/subversion/site/publish/
--- Merging (from foreign repository) r922451 into '.':
Afaq.en.html
% $svn st
~M faq.en.html
% $svn info faq.en.html
Path: faq.en.html
Name: faq.en.html
Working Copy Root Path: /tmp/svn/wc1
URL: file:///tmp/svn/r1/trunk/faq.en.html
Repository Root: file:///tmp/svn/r1
Repository UUID: 0d8f1070-806c-11e0-a89b-a382cea1935c
Node Kind: file
Schedule: add
% file faq.en.html
faq.en.html: ASCII text, with no line terminators
%
]]]
I'll forward this to dev@ (CC'ing you).
Christoph Bartoschek wrote on Tue, May 17, 2011 at 09:24:30 +0200:
Hi,
I have a workarea where I merged in some changes from a completely
different repository. One of the changes was the creation of a link.
After checking in I see that the link is ok in my workarea but not in
any other workarea.
This due to the missing svn:special keyword that was not checked in. How
can this happen?
The following shows inconsistent behaviour in my opinion. How can this
be explained:
esquad$ svn proplist -v tm.h
Properties on 'tm.h':
svn:special
*
esquad$ svn info tm.h
Path: tm.h
Name: tm.h
URL: https://server/trunk/include/tm/tm.h
Repository Root: https://server
Repository UUID: 608964b8-1798-474c-b2d9-552667dc04a5
Revision: 27
Node Kind: file
Schedule: normal
Last Changed Author: christoph
Last Changed Rev: 26
Last Changed Date: 2011-05-16 18:11:17 -0400 (Mon, 16 May 2011)
Text Last Updated: 2011-05-17 02:51:09 -0400 (Tue, 17 May 2011)
Checksum: 1a7ff762ceabb28ca8865f9b0ba377ff
esquad$ svn proplist -v https://server/trunk/include/tm/tm.h
esquad$ svn diff -r HEAD tm.h
This shows that locally the svn:special keyword is set but not on the
server. But svn does not see any difference. Is this a known bug? Or
how can I get the missing keywords checked in?
Christoph
Properties lost on checkin
Hi, I have a workarea where I merged in some changes from a completely different repository. One of the changes was the creation of a link. After checking in I see that the link is ok in my workarea but not in any other workarea. This due to the missing svn:special keyword that was not checked in. How can this happen? The following shows inconsistent behaviour in my opinion. How can this be explained: esquad$ svn proplist -v tm.h Properties on 'tm.h': svn:special * esquad$ svn info tm.h Path: tm.h Name: tm.h URL: https://server/trunk/include/tm/tm.h Repository Root: https://server Repository UUID: 608964b8-1798-474c-b2d9-552667dc04a5 Revision: 27 Node Kind: file Schedule: normal Last Changed Author: christoph Last Changed Rev: 26 Last Changed Date: 2011-05-16 18:11:17 -0400 (Mon, 16 May 2011) Text Last Updated: 2011-05-17 02:51:09 -0400 (Tue, 17 May 2011) Checksum: 1a7ff762ceabb28ca8865f9b0ba377ff esquad$ svn proplist -v https://server/trunk/include/tm/tm.h esquad$ svn diff -r HEAD tm.h This shows that locally the svn:special keyword is set but not on the server. But svn does not see any difference. Is this a known bug? Or how can I get the missing keywords checked in? Christoph
Re: Merging from a foreign repository and svn:id keyword
Am Montag, 14. März 2011 schrieb Stefan Sperling: > On Mon, Mar 14, 2011 at 05:11:03PM +0100, Christoph Bartoschek wrote: > > Hi, > > > > I would like to merge the changes of a directory in repository A to a > > directory in repository B. My problem is that several merges fail because > > of the id keywords. > > > > Svn diff for example shows: > > > > -/* > > -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $ > > It looks like the above Id expansion is from CVS, not from Subversion? > I'd guess the source repository does not have svn:keywords set no this > file, because otherwise it would look different. Oh, you are right, this is an Id line from TCCS our previous software management system. I guess I have to fix this manually. > > -** > > -** $Locker: $ > > -*/ > > +/* $Id$ */ > > The removed Id line cannot be found in repository B because a different > > user created it. It looks like: > > > > ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $ > > > > > > The merge then fails with a conflict because it cannot find the line of > > the diff. How can I let merge ignore conflicts that arise because of > > expanded Id lines? > > Does the file have an svn:keyword property set in your repository? > If so, have you tried removing it? > > Maybe this is due to auto-props settings in your local configuration file? > > > Or how to prevent Id expansion locally and in the diffs? > > It's controlled via svn:keywords properties: > http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords. > html The keyword is set and I do not want to change it because I just want to import the changes from repository A to repository B. The guys that set the keyword definitively want to see it. I want to disable the expansion only for my workarea where I merge the changes from repository A to repository B. If the code is then checked out from repository B the expansion should take place with the new revision numbers. Christoph
Re: Merging from a foreign repository and svn:id keyword
Am Montag, 14. März 2011 schrieb Nico Kadel-Garcia: > On Mon, Mar 14, 2011 at 12:11 PM, Christoph Bartoschek > > wrote: > > Hi, > > > > I would like to merge the changes of a directory in repository A to a > > directory in repository B. My problem is that several merges fail because > > of the id keywords. > > > > Svn diff for example shows: > > > > -/* > > -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $ > > -** > > -** $Locker: $ > > -*/ > > +/* $Id$ */ > > > > The removed Id line cannot be found in repository B because a different > > user created it. It looks like: > > > > ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $ > > > > > > The merge then fails with a conflict because it cannot find the line of > > the diff. How can I let merge ignore conflicts that arise because of > > expanded Id lines? > > > > Or how to prevent Id expansion locally and in the diffs? > > > > Christoph > > The easiest way is to *NOT* use Id and similar keyword expansion, at > all. That's the Linux kernel approach. They can be very, very nasty > indeed to parse and merge. > > Second, pick a single format for comments and keywords and *stick with > it*. The switch in syntax from multi-line commented entries to single > line comment entries is biting you hard here and confusing your diffs > noticeably. > > Sadly, you can't outsmart the ability of people to tweak formats. The > simplest way is to resolve the merge manually. I would like to get rid of Id expansion but I have to use what our group has agreed on. It would help me if I could create a checkout where svn:keywords are not expanded and if I could tell svn merge to also not expand the keywords. Is this somehow possible? If you tell me where to look I could also compile a svn client version for me that prevents the expansion. Basically I think that it should be a one-liner to prevent the expansion. Christoph
Re: Merging from foreign repositories
Am Montag, 14. März 2011 schrieb Stefan Sperling: > On Mon, Mar 14, 2011 at 05:05:14PM +0100, Christoph Bartoschek wrote: > > thanks for your suggestion. But the commit that created dirA also created > > lots of other directories. I am only interessted in dirA. > > Then let's just agree that the other stuff added in that commit > is a merge conflict. So you svn revert -R all of that stuff after > performing the merge and before committing the merge result. > > > I wrote that I want to do this incrementally because I would like to > > replicate each change in directory dirA of repository A to directory > > dirB of repository B with a commit hook. > > Since you're writing hook scripts, it sounds like you have a way to get > an incremental dump file of each revision committed to repository A. > If so, why not load them into repository B using svnadmin load? > > svnadmin dump --incremental --deltas -rREV /path/to/reposA > REV.dump > svnadmin load --parent-dir /branches/fromA /path/to/reposB < REV.dump > > > Apparently this does not work with the commit that creates dirA. It seems > > as if subversion is not able to do this. I will have to do this > > manually. > > You can probably write your hook script to be smart enough to do it. > But I suppose in your situation the dump/load approach is easier than > trying to play tricks with merging. I do not have admin access to repository B. I can only check in into the parent directory of dirB and below. Christoph
Merging from a foreign repository and svn:id keyword
Hi, I would like to merge the changes of a directory in repository A to a directory in repository B. My problem is that several merges fail because of the id keywords. Svn diff for example shows: -/* -** $Id: st_opt_small.c,v 1.3 2004/03/08 17:25:57 mueller Exp $ -** -** $Locker: $ -*/ +/* $Id$ */ The removed Id line cannot be found in repository B because a different user created it. It looks like: ** $Id: st_opt_small.c 2 2011-03-14 15:17:33Z bartosch $ The merge then fails with a conflict because it cannot find the line of the diff. How can I let merge ignore conflicts that arise because of expanded Id lines? Or how to prevent Id expansion locally and in the diffs? Christoph
Re: Merging from foreign repositories
Am Montag, 14. März 2011 schrieb Stefan Sperling: > On Mon, Mar 14, 2011 at 04:08:57PM +0100, Christoph Bartoschek wrote: > > Hi, > > > > I would like to merge all changes in a directory from repository A to a > > directory in repository B. > > > > My idea was to do a loop over all iterations and merge them to dirB: > > > > svn merge -c rev file:///path/to/rep/A/dirA dirB > > > > My problem is that for the revision where dirA is created in repositoryA > > nothing is done. > > > > You see that the first command does nothing although dirA and lots of > > subdirs were created in revision 1. > > The addition of dirA is a change on the *parent* of dirA. > > So merge the parent folder into the target's parent folder first, > preferrably using a two-URL merge (Last time I tried this, with > TortoiseSVN, it would only work with a two-URL merge. I'm not sure if the > CLI client has the same requirement. But since both use the same libraries > that is not unlikely): > > svn merge file:///path/to/rep/A/@rev-1 file:///path/to/rep/A/@rev > parent-dir > > This will add dirA into parent-dir. Commit this. > > Next, you could experiment with renaming dirA to dirB. > But if you ever merge at a higher level in the tree, so that changes > made upstream in dirA appear as part of the diff, you will get tree > conflicts since dirA won't be found at your end. > So not renaming it might save you some headaches later. > I'd recommend keeping the name. > > Now, the following revs can apply cleanly. > There is no need to loop over the revs, you can apply the entire > range at once, giving you single commit that contains all the changes > made upstream. > > svn merge file:///path/to/rep/A/dirA@rev+1 file:///path/to/rep/A/dirA@HEAD > dirA or if you decided to rename: > svn merge file:///path/to/rep/A/dirA@rev+1 file:///path/to/rep/A/dirA@HEAD > dirB > > If you have a real need to cherry-pick individual changes merged from > the foreign repository to branches in your own repository, you will > need to loop over all the revs, of course, and merge them individually. > > Note that there is no merge tracking with foreign repos merges, > so make sure to note which revisions have already been merged from > the foreign repository (e.g. in the log message). Hi, thanks for your suggestion. But the commit that created dirA also created lots of other directories. I am only interessted in dirA. I wrote that I want to do this incrementally because I would like to replicate each change in directory dirA of repository A to directory dirB of repository B with a commit hook. Apparently this does not work with the commit that creates dirA. It seems as if subversion is not able to do this. I will have to do this manually. Unfortunately the automatic merging still does not work after fixing the creation of dirA. I describe it in another main. Christoph
Merging from foreign repositories
Hi, I would like to merge all changes in a directory from repository A to a directory in repository B. My idea was to do a loop over all iterations and merge them to dirB: svn merge -c rev file:///path/to/rep/A/dirA dirB My problem is that for the revision where dirA is created in repositoryA nothing is done. The next revision then fails because it misses a directory: $ svn merge -r 0:1 file:///path/to/rep/A/dirA . $ svn merge -r 1:2 file:///path/to/rep/A/dirA . --- Merging (from foreign repository) r2 into '.': C utils Summary of conflicts: Tree conflicts: 1 You see that the first command does nothing although dirA and lots of subdirs were created in revision 1. How can this be fixed? Christoph
Re: svn:externals format
Am Dienstag, 16. November 2010 schrieb Stefan Sperling: > On Tue, Nov 16, 2010 at 01:43:35PM +0100, Christoph Bartoschek wrote: > > Hi, > > > > what is the advantage of using > > > > ^/trunk/project/subproj...@40 subproject > > This new format does support relative URLs. > > > compared to > > > > -r 40 ^/trunk/project/subproject subproject > > This old format doesn't support relative URLs. > You can only use full URLs (http://svn.example.com/...) with this format. > > See "svn help propset" for more information. svn help propset states that relative URLs also work for the old format. We currently use the old format with relative URLs: "Relative URLs are supported in Subversion 1.5 and greater for all above formats and are indicated by starting the URL with one of the following strings" Christoph
svn:externals format
Hi, what is the advantage of using ^/trunk/project/subproj...@40 subproject compared to -r 40 ^/trunk/project/subproject subproject ? Is it the case that the first version works if ^/trunk/project/subproject is deleted in a later revision and the second version fails? Christoph
Re: svn export bug in 1.6.13
Am Dienstag, 9. November 2010 schrieb Stefan Sperling: > https://svn.apache.org/repos/asf/subversion/branches/1.6.x-issue3727 > > Please note that my fix hasn't been reviewed yet by other developers. > If you encounter problems using this fix please let me know. Thanks, works for us as expected. Christoph
Re: svn export bug in 1.6.13
> The bug has been fixed in trunk. The fix has not been nominated for > backport to 1.6.x yet but I will do so shortly. > > Until the fix appears in a new Subversion release, you can go back to > 1.6.12. Alternatively, if you feel comfortable compiling svn yourself from > source, you will be able to check out a branch from our repository that > contains recent 1.6.x code (currently very close to 1.6.13) plus the fix. > If you want to do that let me know and I'll send you the URL once it > exists. Yes, I would like to compile the recent 1.6.x code with the fix. Please send me the URL. Thanks Christoph
Re: svn export bug in 1.6.13
Am Freitag, 29. Oktober 2010 schrieb Daniel Shahaf: > http://subversion.tigris.org/issues/show_bug.cgi?id=3727 > > Chris Seawood wrote on Fri, Oct 29, 2010 at 10:04:17 -0700: Hi, our workflow currently does not work due to this bug. Is there a fixed 1.6.13 version in the repository we can check out to replace the broken 1.6.13? Or do you recommend that one goes back to 1.6.12? Chrsitoph
Filtering to remove externals
Hi, we are using the following layout for several years now: 1. We have one repository repo. 2. There are several projects in the repository: repo/a repo/b repo/c Each project has the standard layout trunk/tags/branches. 3. Then there is a product build from the projects (repo/Product) that includes the projects with svn:externals pointing to trunk of each project. The users checkout the product and work in this directory. We would like to change the situation because a) often a single commit should touch more than one project. b) when we check out an earlier version one makes easily mistakes because the externals point to trunk. c) setting up branches of the project is a pain. The change we plan results in a single project that consists of the product with only a single branches/tags/trunk layout. To unify the workflow with older releases I would like to rewrite the current history such that the result looks like we have used the new layout from the beginning. How can this be achieved? Christoph
Re: Problems during merge
Am Donnerstag, 11. Februar 2010 schrieb Neels J Hofmeyr: > Hi Christoph, > > it would be nice if you could provide a way to reproduce this issue. I am > aware that this can be some work, and we would highly appreciate it. :) Hi, here is the script. When it comes to choosing the merge operation I choose (p). The file dir_b/file has the wrong conflict markers. Christoph merge_fail.sh Description: application/shellscript
Problems during merge
Hi,
after a merge with conflicts I completely wrong conflict markers:
=== inv_merge.C =
...
} else {
<<< .working
===
_cur.sinks(to_polarity(other)).append(csol.sinks());
>>> .merge-right.r13821
_cur.sinks(to_polarity(other)).append(csol.sinks());
Time slew_limit =
...
==
In my working copy there is:
=== inv_merge.C.working ==
...
} else {
_cur.sinks(to_polarity(other)).append(csol.sinks());
Time slew_limit =
...
==
The right part only differs in an empty line:
=== inv_merge.C.merge-right.r13821 ===
...
} else {
_cur.sinks(to_polarity(other)).append(csol.sinks());
Time slew_limit =
...
==
In the left part we have:
=== inv_merge.C.merge-left.r13820 ===
...
} else {
_cur.sinks(to_polarity(other)).append_slice(csol.sinks().begin(),
csol.sinks().size());
TimePair slew_limit =
...
==
I would have expected that I see the code of the left part in the merge view
and not two times the code from working.
What is going wrong here?
Christoph
Accessing HTTP subversion server via SSH tunnel
Hi, owr http subversion server is in network A. I am in network B and can only access network A via a ssh login on a machine that is in both networks. Is there an easy way to use the svn client in network B such that it tunnels over ssh to the http server in network A? Thanks Christoph
