Re: Revision number where a file is deleted is NOT visible in the file's history, but buried in the folder's history - Please document that in svnbook, and add a FAQ
free.fr> writes: > A naive goal is to display the whole history of the 'myFolder/myFile' file, > INCLUDING the number and message of the revision where the file has > been deleted. Agreed, this is a big hassle. I posted a similar complaint a while ago. My suggestion was to add an option to "svn log", so it could give you the history of anything that was ever at a given path. http://svn.haxx.se/users/archive-2009-12/0219.shtml JW
Branch from a branch: moving to a normal branch
I normally create branches from trunk, work on them, and eventually reintegrate them back into trunk. Sometimes I'll create a branch Y from another branch X, so I can start with X's code. Normally I'll reintegrate Y into X first, then reintegrate X into trunk. Y --> X --> trunk But what if I want to reintegrate X into trunk first, and I no longer want Y to depend on X? In other words, I want Y to be a normal branch, so that I can merge it directly to and from trunk, without going through X. Y --> trunk X --> trunk What should I do? One approach would be to create a new branch, and merge all of Y's changes into it. But I'd like to keep using Y if possible, so I don't lose track of its history. Is that possible? Jacob
Diff output: get full path of files
I want to pass the output of "svn diff OLD-URL NEW-URL" to a code-review tool, but I need to include the full path of each file in the ---/+++ headers. The paths in the output always seem to be relative to the directories you pass in. Is there a way to make it include the full paths? Thanks, Jacob
Re: Diff output: get full path of files
I'm looking for the repository-relative paths. It seems like I get these in some cases, but not others. For example, if I give it two URLs: svn diff https://repos/proj1/dir1/dir2https://repos/proj2/dir1/dir2 I get something like this, with the repository-relative paths in parentheses, prefixed by "...": Index: file1 === --- file1 (.../proj1/dir1/dir2) (revision 103644) +++ file1 (.../proj2/dir1/dir2) (revision 103644) But if I give it two revisions and a single URL: svn diff -r100:200 https://repos/proj1/ I get something like this, with no repository-relative paths in parentheses: Index: dir1/dir2 === --- dir1/dir2 (revision 103537) +++ dir1/dir2 (revision 103538) Jacob On Oct 24, 2011, at 2:11 PM, Philip Martin wrote: > Jacob Weber writes: > >> I want to pass the output of "svn diff OLD-URL NEW-URL" to a >> code-review tool, but I need to include the full path of each file >> in the ---/+++ headers. >> >> The paths in the output always seem to be relative to the directories >> you pass in. Is there a way to make it include the full paths? > > The paths in the standard diff output are repository relative paths. If > you want the paths to local copies of the files use --diff-cmd to invoke > your own wrapper, the files paths are parameters 6 and 7. > > -- > Philip
Re: Diff output: get full path of files
On Oct 24, 2011, at 2:41 PM, Jacob Weber wrote: > For example, if I give it two URLs: > svn diff https://repos/proj1/dir1/dir2https://repos/proj2/dir1/dir2 > > I get something like this, with the repository-relative paths in parentheses, > prefixed by "...": > Index: file1 > === > --- file1 (.../proj1/dir1/dir2) (revision 103644) > +++ file1 (.../proj2/dir1/dir2) (revision 103644) Sorry, have to correct myself. I don't always get the repository-relative paths in that case. If the leading paths of the two URLs are the same, it omits those: svn diff https://repos/proj1/dir1/dir2https://repos/proj1/dir1/dir3 Index: file1 === --- file1 (.../dir1/dir2) (revision 103644) +++ file1 (.../dir1/dir3) (revision 103644) Jacob
Branch from a branch -- will merges still work?
I'm wondering if the following pattern will work: - a branch A from trunk, where features are developed, before they're released into trunk - a branch AA from A, where more experimental features are developed, before they're released into A, and then eventually into trunk. This way, while A's features are still being tested, new features based on them can be developed. My concern is this: After we reintegrate from A into trunk, we'll need to revert A to trunk (according to my understanding of reintegrate merges.) So once we do that, will we still be able to reintegrate from AA into A, or will their connection be broken? Is there a better way to achieve the same result (being able to do new development based on still-unreleased changes)? Thanks, Jacob
Partially reintegrate changes
Let's say I have a branch where I develop two features, X and Y. I then want to merge only X back into the trunk. I want to do some further development on Y, and merge it into trunk later. Is this possible with Subversion? If I do a reintegrate into trunk, I could revert all the changes for Y, keeping only X. But then, since you have to revert your branch after a reintegrate, I would lose Y. Is there another way? Thanks, Jacob
Re: Branch from a branch -- will merges still work?
On Feb 18, 2010, at 8:00 AM, Rob van Oostrum wrote: > On Thu, Feb 18, 2010 at 10:17 AM, Jacob Weber wrote: > My concern is this: > After we reintegrate from A into trunk, we'll need to revert A to trunk > (according to my understanding of reintegrate merges.) So once we do that, > will we still be able to reintegrate from AA into A, or will their connection > be broken? > > Is there a better way to achieve the same result (being able to do new > development based on still-unreleased changes)? > > > If you need to keep A around after reintegration to trunk, all you need to do > is do a --record-only merge back to your branch to avoid merge conflicts > (caused by the reintegration merge) when bringing in additional trunk changes. > > No reason your proposed solution couldn't work. Do you mean that I don't need to delete my branch after a reintegrate, as suggested here: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate and that instead, I can just record the revision of the merge as having being merged into my branch? You may have just changed my life, sir. :) Jacob
Re: Partially reintegrate changes
On Feb 18, 2010, at 7:37 AM, Mark Phippard wrote: > On Thu, Feb 18, 2010 at 7:17 AM, Jacob Weber wrote: >> Let's say I have a branch where I develop two features, X and Y. I then want >> to merge only X back >> into the trunk. I want to do some further development on Y, and merge it >> into trunk later. >> >> Is this possible with Subversion? > > Yes. When merging from branch to trunk, you would need to specify the > specific revisions to merge. You could not use reintegrate. Let's > assume when you commit this merge to trunk that revision 200 is > created. > > Back on the branch you should run: > > svn merge --record-only -c200 ^/trunk > > To record the merge. Now you can just do normal synch merges with > trunk and reintegrate the branch when you are done. Thanks! I'll give that a try. But I was under the impression that if I did a non-reintegrate merge back into the trunk, it would cause self-referential mergeinfo to be written there. That is, the trunk would have mergeinfo for the trunk. And then that ends up screwing up things later on. Or am I wrong about that? Maybe the self-referential mergeinfo I saw was being introduced some other way. Thanks, Jacob
Re: Branch from a branch -- will merges still work?
Nice! Stefan, if you're the one who added it, you might also want to link to it in the section I mentioned, where it says "once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work". Jacob On Feb 18, 2010, at 8:51 AM, Stefan Sperling wrote: > On Thu, Feb 18, 2010 at 11:22:36AM -0500, Rob van Oostrum wrote: >> On Thu, Feb 18, 2010 at 11:19 AM, Jacob Weber wrote: >>> Do you mean that I don't need to delete my branch after a reintegrate, as >>> suggested here: >>> >>> >>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate >>> >>> and that instead, I can just record the revision of the merge as having >>> being merged into my branch? >>> >>> You may have just changed my life, sir. :) >>> >> You don't need to. The suggestion on that page is just that if you no longer >> need the branch, it's perfectly safe to remove it (since you can always >> resurrect it if need be). > > See this section of the book for a more thorough explanation: > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice > > It was added to the book just yesterday, so it's understandable > that you missed it :) > > Stefan
Re: Partially reintegrate changes
Stein Somers: > I see some self-refenertial mergeinfo in our /trunk, after lots of > merges to and from. Maybe I explicitly added it with a record-only in > some state of confusion. But it doesn't scare me at all. It would only > matter if you explicitly merged /trunk to /trunk. And then, as far as I > can tell, it would only cause svn merge to do less than it does without > the self-refenertial mergeinfo, and as far as I can tell a > self-referential foward merge doesn't do anything anyway. It does scare me a little. When I have self-referential mergeinfo, it causes problems with "svn log -g" (show merged revisions). It gets confused and shows me ALL revisions in the branch, from the time it was created. So the command takes forever, and returns way too much data. Jacob
Strange output from reintegrate merge using JavaHL
Sometimes when I do a --reintegrate merge, I get some unexpected output, along with the normal updates: --- Merging differences between repository URLs into trunk-path U /trunk-path/file1 U trunk-path/file2 trunk-path/file3 trunk-path/fil4 ... That is, I see a bunch of filenames that have no status indicator. There were hundreds of them in my latest merge. I'm using a Subversion 1.6.5 client, through Subclipse, using the JavaHL interface, connecting to a 1.6.5 server. This output seems to be the result of a call to: org.tigris.subversion.javahl.mergeReintegrate(branch-url, HEAD, trunk-path, false). Does anyone know why this might happen? Thanks, Jacob
Certain files always appear in my reintegrate merges
Here's the situation: I just did a reintegrate from the HEAD of branch_X into trunk. I committed everything. At this point, the two branches should be identical. Afterwards, I didn't change either branch, except to commit the reintegrate itself to trunk, and to commit a record-only merge to branch_X, to block the reintegrate from being merged back. Now I update my copy of trunk, and repeat the exact same merge. I should see no changes, right? Wrong. I see two PDF files, that Subversion thinks were updated. EVERY TIME I do a reintegrate from this branch, these same two files show up as updates. Nobody is touching the files, and their contents are identical in both branches. Why is this happening? Jacob
Re: Certain files always appear in my reintegrate merges
Forgot to mention: I'm using SVN 1.6.11 client and 1.6.5 server. Jacob On May 22, 2010, at 7:31 PM, Jacob Weber wrote: > Here's the situation: I just did a reintegrate from the HEAD of branch_X into > trunk. I committed everything. > > At this point, the two branches should be identical. Afterwards, I didn't > change either branch, except to commit the reintegrate itself to trunk, and > to commit a record-only merge to branch_X, to block the reintegrate from > being merged back. > > Now I update my copy of trunk, and repeat the exact same merge. I should see > no changes, right? > > Wrong. I see two PDF files, that Subversion thinks were updated. EVERY TIME I > do a reintegrate from this branch, these same two files show up as updates. > Nobody is touching the files, and their contents are identical in both > branches. > > Why is this happening? > Jacob
Can't merge after changing directory capitalization
If I change the capitalization of a directory name, it seems to cause problems with merging. I'm using SVN 1.6.11 on Mac OS X. I'm not sure if this is relevant, but OS X doesn't support multiple files in the same directory with the same name and different capitalization. Can I report this as a bug? Do you need any more information? Here's a test case: # create trunk and directory svn mkdir -m "" $REPOS/hello rm -rf hello svn checkout $REPOS/hello hello mkdir hello/test svn add hello/test svn commit -m "" hello # create branch svn copy -m "" $REPOS/hello $REPOS/hello-br # remove the directory, and create a new one with a different capitalization rm -rf hello/test svn rm hello/test svn commit -m "" hello mkdir hello/TEST svn add hello/TEST svn commit -m "" hello # merge trunk into branch rm -rf hello-br svn checkout $REPOS/hello-br hello-br svn merge --accept theirs-full $REPOS/hello hello-br At this point I get an error: svn: Working copy 'hello-br/TEST' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Running the cleanup command doesn't help. Jacob
Re: Can't merge after changing directory capitalization
On Aug 16, 2010, at 10:27 AM, Ryan Schmidt wrote: > On Aug 16, 2010, at 12:08, Jacob Weber wrote: > >> OS X doesn't support multiple files in the same directory with the same name >> and different capitalization. > > Just to nitpick this point: of course Mac OS X supports that. But the > case-insensitive Mac OS Extended filesystem most Macs use doesn't support > that. Fair point. Still, I think this is a legitimate problem -- there's nothing here that should require those two files to exist at the same time. And this is the default filesystem for most Macs, so people are likely to run into the problem. Jacob
Possible bug: "Searching tree conflict details" takes forever
Hi there. I'm doing a merge which seems to be doing a very long-running operation (over an hour so far) when it gets to the "Searching tree conflict details" step. I'm wondering if there's any way to avoid this. I'm merging from a branch X where a directory was removed, into a branch Y where that same directory was removed. In each case, the removal was actually done as part of a reintegrate merge from a different branch. I can reproduce this every time I revert and restart the merge. Unfortunately I can't share the content of my repository. The output is something like this: $ cd branchY $ svn update $ svn merge ^/branchX --- Recording mergeinfo for merge of r1 through r2 into '.': U . --- Merging r20001 through r20100 into '.': Afoo Abar G . --- Recording mergeinfo for merge of r20001 through r20100 into '.': G . Summary of conflicts: Text conflicts: 2 Tree conflicts: 7 Searching tree conflict details for 'path/to/conflict/dir' in repository: Checking r9000... At this point it slowly starts decreasing the revision after "Checking". But it seems to be going through my entire repository history, which will take forever. Is there any way to avoid this? Mac OS 10.14.6 SVN client 1.14.0, compiled Jul 4 2020, 20:57:11 on x86_64-apple-darwin18.7.0 SVN server 1.8.13
Re: Possible bug: "Searching tree conflict details" takes forever
Thanks Stefan. --accept=postpone sounds like just what I need. I ended up discovering that if I committed an empty directory in the location of the conflict, it would skip the deep history search, and show a different tree conflict right away. So that got me out of waiting. But I'll try --accept=postpone next time. You're right — I removed most of the real merge results from my example. I don't think I'm going to be able to create a reproducible repository, unfortunately (it's proprietary). Jacob > On Aug 4, 2020, at 1:51 PM, Stefan Sperling wrote: > > On Tue, Aug 04, 2020 at 06:37:07PM +, Jacob Weber wrote: >> Hi there. I'm doing a merge which seems to be doing a very long-running >> operation (over an hour so far) when it gets to the "Searching tree conflict >> details" step. I'm wondering if there's any way to avoid this. >> >> I'm merging from a branch X where a directory was removed, into a branch Y >> where that same directory was removed. In each case, the removal was >> actually done as part of a reintegrate merge from a different branch. >> >> I can reproduce this every time I revert and restart the merge. >> Unfortunately I can't share the content of my repository. >> >> The output is something like this: >> >> $ cd branchY >> $ svn update >> $ svn merge ^/branchX >> --- Recording mergeinfo for merge of r1 through r2 into '.': >> U . >> --- Merging r20001 through r20100 into '.': >> Afoo >> Abar >> G . >> --- Recording mergeinfo for merge of r20001 through r20100 into '.': >> G . >> Summary of conflicts: >> Text conflicts: 2 >> Tree conflicts: 7 > > The above per-path output shows no new conflicts. I suppose you were actually > seeing lines such as "Cfoo" somewhere, and they are just missing from > your example? > >> Searching tree conflict details for 'path/to/conflict/dir' in repository: >> Checking r9000... >> >> At this point it slowly starts decreasing the revision after "Checking". But >> it seems to be going through my entire repository history, which will take >> forever. >> >> Is there any way to avoid this? > > Yes. The option: --accept=postpone > for svn merge will bypass the conflict resolver and flag a tree conflict > in the working copy. > > This conflict still needs to be resolved before the merge result can be > committed. Note that 'svn resolve' will try to scan history again, so you > will need to use some non-interactive variant of this command. > > If one of the --accept option paremeters achieve the result you want to > resolve to, then you could use --accept with a suitable parameter (see > the output of 'svn help resolve' for a list). > > Otherwise, use this command to simply clear the conflict marker: > svn resolve --accept=working path/to/conflict/dir > And then resolve the actual conflict manually as required. > >> Mac OS 10.14.6 >> SVN client 1.14.0, compiled Jul 4 2020, 20:57:11 on >> x86_64-apple-darwin18.7.0 >> SVN server 1.8.13 > > Some conflicts may be avoided if the server was upgraded to SVN 1.10 or later. > Newer servers can help with avoiding some tree conflicts. > See for example, see https://svn.apache.org/r1760570 -- this bug should > affect you since it was first fixed in 1.9.5. Though I doubt it is related > to your problem at hand since it looks like your conflict is on a directory > rather than a file. > > Unfortunately, deep history crawls cannot always be avoided. Since information > shown by the resolver can save people a lot of time trying to figure out what > happened, it is considered acceptable that the resolver may take a while to > obtain this information. > > Of course, an hour is outside of this acceptable scope. There could also be > a bug to fix in this case. We've found and fixed similar problems before, > for example here: https://svn.apache.org/r1839662 (this particular problem > does *not* affect you since are using a 1.14 client). > But in order to figure this out we'd need a lot more information from you. > Ideally, a script which starts off with an empty repository, populates it > (with deep history if necessary), and then runs a series of SVN commands > which ends in a merge that triggers the problem. > > Cheers, > Stefan >
reintegrate in 1.8.1
According to the SVN 1.8 release notes: "Merging to-and-fro between two branches in any order is possible using the automatic reintegration merge (the "keep-alive dance" is no longer necessary)." So say I merge from a branch into trunk (i.e. what used to be a reintegrate), creating revision X. Does this mean I no longer need to run a --record-only merge to block X from being merged back into my branch? The next time I merge from trunk into my branch, how will SVN know not to merge X? Thanks, Jacob
Re: reintegrate in 1.8.1
On Aug 27, 2013, at 1:39 PM, Mark Phippard wrote: > On Tue, Aug 27, 2013 at 4:34 PM, Jacob Weber wrote: > The next time I merge from trunk into my branch, how will SVN know not to > merge X? > > Magic :) > > Internally, the code still does reintegrate. It just figures out when it > needs to do it. It turns out you could have always avoided doing > --record-only, but only if you "knew" to use --reintegrate on that first > merge from trunk back to the branch. SVN figures this out and is doing it > for you. > > If you are merging between branchA and branchB, if the last merge between > those two branches went in the "same direction" it does a sync merge, if it > went in the "opposite direction" it does a reintegrate merge. Nice. Doing --record-only won't hurt though, will it? I'm concerned that some people might be accessing my repository with a 1.7 client, so this magic wouldn't work for them. I was under the impression that reintegrate just did a two-way diff of the two branches, and applied the differences to the destination branch (from the 1.7 manual: "By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)") But I'm guessing from what you said that it's more complex than this. Otherwise, if you had changes in the trunk that hadn't been merged into a branch, you would lose them when you reintegrated from the branch back into the trunk. Jacob
