Reintegrate unexpected issue
Hi everybody, I try to reintegrate a branch into my trunk but when I execute the following command : svn merge --reintegrate svn://bt1svzyi/rnv/branches/13.5 I have this error : This application has halted due to an unexpected error. A crash report and minidump file were saved to disk, you can find them here: P:\TEMP\svn-crash-log20130612121533.log P:\TEMP\svn-crash-log20130612121533.dmp Please send the log file to users@subversion.apache.org to help us analyse and solve this problem. NOTE: The crash report and minidump files can contain some sensitive information (filenames, partial file content, usernames and passwords etc.) If somebody help me thanks in advance. Best Regards, Guillaume C. L'int?grit? de ce message n'?tant pas assur?e sur internet, la soci?t? exp?ditrice ne peut ?tre tenue responsable de son contenu ni de ses pi?ces jointes. Toute utilisation ou diffusion non autoris?e est interdite. Si vous n'?tes pas destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender. svn-crash-log20130612121533.dmp Description: svn-crash-log20130612121533.dmp svn-crash-log20130612121533.log Description: svn-crash-log20130612121533.log
Apache Subversion 1.8.0-rc3 Released
I'm happy to announce the release of Apache Subversion 1.8.0-rc3, the second public release candidate of Subversion 1.8.0 (rc1 was not publicly released). Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums are: 5abfb2add2fb0c4bb576a2b423965a9fcd337778 subversion-1.8.0-rc3.tar.bz2 9862d38ae6964b3aa87ce1957365a8d0cc8971ca subversion-1.8.0-rc3.tar.gz f3ba0e035355356793f87849368325595dba78aa subversion-1.8.0-rc3.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.0-rc3.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.0-rc3.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.0-rc3.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 C. Michael Pilato [4096R/FE681333] with fingerprint: 753B 2F9D F717 FA23 A43E E7C3 F5E0 F001 FE68 1333 Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [2048R/9A59B973] with fingerprint: 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 This is a release candidate for what will eventually become Apache Subversion 1.8.0. It is thought to be free of blocking issues, and if none are found will become the final release. For this reason, we encourage thorough testing in as many environments as possible. This release candidate puts us in the last week of the four-week "soak" period to allow for further testing, and barring show-stopping bugs, the final 1.8.0 release can be expected on or near June 18th. A pre-release means the Subversion developers feel that this release is ready for widespread testing by the community. There are known issues (and unknown ones!), so please use it at your own risk, though we do encourage people to test this release thoroughly. Of particular note, please remember than persistent data, such as the working copy or repository formats may change before the final release, and there may not be an upgrade path from the pre-releases to the final. As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. Release notes for the 1.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.0-rc3 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.0-rc3/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: History in subversion
Thanks All for your help and advices, >> From: Les Mikesell : > svn logs will show file/directory additions/deletions in the parent directory, so you should be able to track the history of things that way if you wanted, but what is it that you specifically need to do? > Most people would just check out some directory level and diff it against some other revision or a branch or tag. Ok, svn log -v will help, But : With CC, I can easily search for any file element in a repository, and directly get its path, With SVN, I have to check all revisions, then I can know where this element is located in the repository (maybe several locations), I can find in which revision it was removed. This is double manual search. When users ask for help, I have to go in their repository that I don't know at all, users often give less than half the information I need to locate the file where they need help. With CC, I can quickly analyze a repository, and get easily the missing information. With SVN, I feel like blind, because I cannot do the same analysis on the repository. I cannot do a global search, I have to check the revisions individually. About peg revision : Peg revision means that I can access any file and directory "version" without checkout, this is already a nice help. But : is there also an individual identifier for directory and file (uuid, oid, ..) ? >> From: Andrew Reedick > I used to use ClearCase in a past life (3.0 - 6.0). I haven't missed the ability to diff dirs. You might be stuck on doing things the CC way instead of learning the Subversion paradigms. It's going to be frustrating for a little while (it was for me.) > What are you trying to do that requires diff'ing the contents of directories? Could you help more on diff dirs, please : - What is the best way with SVN to compare a same directory on two different branches ? I am very confused by many things with SVN, one of them is : - I can merge from any directory to any directory anywhere, and I just get a terrible Tree conflict. With CC, the merge is inside the version tree of the file or directory element. This kind of mistake is not possible. I don't understand why it is done like this with SVN. I did not understand everything with branches and tags, I have to read again the manual, but I have the feeling that branches and tags are not linked, this is strange to me. >> From: Andrew Reedick > To re-emphasize, I'm very serious about the need to stop trying to apply CC paradigms to SVN. It's frustrating, and, in my experience, the CC way of doing things didn't provide significant advantages in (or over) SVN. I understand, and I don't try to use SVN "in the CC way". SVN and CC are tools, the goal for me is the software configuration management of the projects, and also to be able to help the users of the tools in the best way. On the other hand, I'd like to understand and compare the capabilities of both tools by myself, because what I read in the past was not detailed enough in my opinion. Thanks 2013/6/11 Olivier Antoine > Hi, > > I'm trying to work with SVN, but coming from ClearCase, I'm lost. > > It seems that it is not possible to consult the history of the repository > like in CC, > I can get the history of a file element with svn+annotate, I can use > svn+diff on files, > But for directories : no annotate, no diff - nothing ? > Do I have to check all the repository revision set in order to follow the > changes on a directory element ? > > Regards > Olivier > >
Request for nice feature to solve tree conflict on moved/renamed files
Hi, I just faced this problem: Had to fix a bug in an older, but still supported version of my application. After the fix I merged the range of revisions to the trunk and got a "tree conflict". Yes, that file was moved and renamed, maybe there is a loss of information in the merge tracking, don't know. I tried to solve it by creating a patch of the file and apply it to the file in the trunk, but that's impossible. Applying a patch is only available on directories. At least I did the merge "by hand" (not much modifications). What I would like to request is - either a possibility to apply a diff to a single file (even if it's renamed / moved) or - in the merge dialog right click on that file with "tree conflict" and select a file to apply the modifications to Good night Torge
Re: History in subversion
On Wed, Jun 12, 2013 at 2:41 PM, Olivier Antoine wrote: > > > Ok, svn log -v will help, > > But : > > With CC, I can easily search for any file element in a repository, and > directly get its path, > With SVN, I have to check all revisions, then I can know where this element > is located in the repository (maybe several locations), I can find in which > revision it was removed. > This is double manual search. That's not what most people do with subversion most of the time... There is a tool called fisheye: http://www.atlassian.com/software/fisheye/overview that will maintain a full-text search index and track a bunch of stats if you need real search capability. > When users ask for help, I have to go in their repository that I don't know > at all, users often give less than half the information I need to locate the > file where they need help. > With CC, I can quickly analyze a repository, and get easily the missing > information. > With SVN, I feel like blind, because I cannot do the same analysis on the > repository. I cannot do a global search, I have to check the revisions > individually. Agreed, it works better if you know where you put the things that you'll want back. > About peg revision : > Peg revision means that I can access any file and directory "version" > without checkout, this is already a nice help. > But : is there also an individual identifier for directory and file (uuid, > oid, ..) ? The revision number is global for every object in the repository and changes atomically with each operation. So you can use a peg revision with any path element to make it a unique identifier. > Could you help more on diff dirs, please : > - What is the best way with SVN to compare a same directory on two different > branches ? Just check one out and diff the workspace against a different revision or branch path or both. > I am very confused by many things with SVN, one of them is : > - I can merge from any directory to any directory anywhere, and I just get a > terrible Tree conflict. Well, if that's not what you want, don't do that... Or revert when you see it is wrong. A lot of things will make more sense if you understand that subversion just manages arbitrary directories and the revision histories of them and the files contained there. Copying a directory takes that history along, so you can use directory copies as branches and tags, but it is entirely up to you to set up and follow your own conventions of where they are and what they are named. Subversion doesn't really care where the copy goes or whether you subsequently try to merge from somewhere else, but if the histories don't have much in common a merge probably isn't going to make sense. > With CC, the merge is inside the version tree of the file or directory > element. This kind of mistake is not possible. > I don't understand why it is done like this with SVN. Subversion doesn't know/care where in the tree you put what you want to call a project. Sometimes that is a good thing. > I did not understand everything with branches and tags, I have to read again > the manual, but I have the feeling that branches and tags are not linked, > this is strange to me. Linked to what? Think of them as 'cheap copies' of whatever they are copied from. And remember that subversion doesn't really know or care that they are branches or tags - that's your convention and if you follow it everything works fine. >> To re-emphasize, I'm very serious about the need to stop trying to apply >> CC paradigms to SVN. It's frustrating, and, in my experience, the CC way of >> doing things didn't provide significant advantages in (or over) SVN. > > I understand, and I don't try to use SVN "in the CC way". SVN and CC are > tools, the goal for me is the software configuration management of the > projects, > and also to be able to help the users of the tools in the best way. The 'best' way isn't necessarily the same for everyone, but you do need to understand that subversion doesn't force any usage style or layout so it is important to have and follow conventions. > On the other hand, I'd like to understand and compare the capabilities of > both tools by myself, because what I read in the past was not detailed > enough in my opinion. Have you read "The" book: http://svnbook.red-bean.com/ ? If you have, try again to get a better understanding of what subversion operations are inherent in the server/repository and what are just conventions or client-side concepts. The idea of merge-tracking does make this part a little fuzzy. -- Les Mikesell lesmikes...@gmail.com
RE: History in subversion
> From: Olivier Antoine [mailto:oliviera201...@gmail.com] > Sent: Wednesday, June 12, 2013 3:42 PM > To: users@subversion.apache.org > Subject: Re: History in subversion > > Thanks All for your help and advices, > But : > > With CC, I can easily search for any file element in a repository, and > directly get its path, > With SVN, I have to check all revisions, then I can know where this element > is located in the repository (maybe several locations), I can find in which > revision it was removed. > This is double manual search. You cannot directly diff two revisions of a directory, where diff is defined as diff'ing the list of file/dir objects in the directory. Instead, SVN will diff the files under the directory tree. From a CC point of view, svn file objects are first class objects with version a version tree, history, etc., whereas SVN directory objects are not. (SVN dirs are second class-ish.) This should help you to find files and what rev they're in. '^/' is the path or svn url to check. Foo.java is the file or regex you're looking for. svn log -v -q ^/ | perl -ne '$r=$_ if /^r\d+/; print $r, $_ if /foo.java/;' > When users ask for help, I have to go in their repository that I don't know > at all, users often give less than half the information I need to locate the > file where they need help. > With CC, I can quickly analyze a repository, and get easily the missing > information. > With SVN, I feel like blind, because I cannot do the same analysis on the > repository. I cannot do a global search, I have to check the revisions > individually. If you're just trying to find a file in the current version of the repo, then "svn ls -R svn://..." You can use '-r' and peg revisions to search older revisions of the repo tree. > About peg revision : > Peg revision means that I can access any file and directory "version" without > checkout, this is already a nice help. > But : is there also an individual identifier for directory and file (uuid, > oid, ..) ? There's no such thing as a uuid or oid in SVN (or at least one that is user visible.) Instead, you can use "svn_url + revision number" or "svn_url + 'Last Changed Rev'" (which can be found via 'svn info') in order to uniquely identify a particular revision of something. 'Last Changed Rev' is preferable. However, since SVN doesn't have true renames, 'svn copy' will normally create a new object with a new revision (aka last changed rev) number. A new revision number won't be created if you copy the parent dir the file is in. In CC parlance, instead of /repo/branches/1.0/foo.java and /repo/trunk/foo.java just being hard links to revision object #1452134521, in svn you wind up with either a new revision number: 1. svn copy /repo/trunk/foo.java /repo/branches/1.0/foo.java 2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java ... Last Changed Rev: 100 ... Last Changed Rev: 123 Or if you copy the parent dir, foo.java's rev number remains unchanged: 1. svn copy /repo/trunk /repo/branches/1.0 2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java ... Last Changed Rev: 100 ... Last Changed Rev: 100 So technically yes, SVN has the Evil Twin problem, however, it doesn't really cause problems with file merges per se, so Evil Twins aren't really a problem. Directory tree merges on the other hand, can be murder, but tree conflicts have been greatly improved in 1.7. > Could you help more on diff dirs, please : > - What is the best way with SVN to compare a same directory on two different > branches ? 'svn diff', or checkout/export both branches (directories) and run your favorite diff tool on them. If you want to diff the contents of the dirs (i.e. the hard links,) then you can try 'svn ls -v' and diff the output (look at the rev numbers.) Generally speaking, in SVN, you don't diff directories, you diff the files in the baselines (aka branches.) However, since SVN revisions are changesets (a collection of related changes,) you can also use 'svn mergeinfo' to "diff" two baselines/branches/directories (i.e. find what changes have not been applied from branchA to branchB.) Or you can just run the merge command to see what would get merged and then 'svn revert -R' to get back to a clean workspace (instead of checking in.) You can even do a a 'svn merge --ignore-ancestry' to merge unrelated trees (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata) Long story short, if you are managing changesets between branches, then svn is quite adequate. If you're diffing code trees, then something has gone wrong with your merges and/or change management process. =) > I am very confused by many things with SVN, one of them is : > - I can merge from any directory to any directory anywhere, and I just get a > terrible Tree conflict. > With CC, the merge is inside the version t
Re: Request for nice feature to solve tree conflict on moved/renamed files
Guten Tag Torge Riedel, am Mittwoch, 12. Juni 2013 um 21:56 schrieben Sie: > - in the merge dialog right click[...] Sounds you should post your request to the TorotiseSVN mailing list. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: History in subversion
On Wed, Jun 12, 2013 at 10:45 PM, Les Mikesell wrote: > On Wed, Jun 12, 2013 at 2:41 PM, Olivier Antoine > wrote: ... >> Could you help more on diff dirs, please : >> - What is the best way with SVN to compare a same directory on two different >> branches ? > > Just check one out and diff the workspace against a different revision > or branch path or both. Or 'svn diff --old=^/branches/branch1 --new=^/branches/branch2' (The ^/ syntax is shorthand for the repository root, when your current working directory is inside a working copy (so svn can discover what repository you're referring to). On Windows you have to escape the ^, so it becomes ^^/). In 1.8 you'll no longer need the --old / --new options for comparing two arbitrary URLs, you can just type: svn diff ^/branches/branch1 ^/branches/branch2 -- Johan
Re: Unicode characters in filenames on windows
Branko Čibej wandisco.com> writes: > > On 12.06.2013 02:58, Варфоломеев Игорь wrote: > > Hi all, > > I'm still not sure if it's a bug, or if I'm doing something wrong. But I'm unable to get TortoiseSVN > > command-line tool to work with files with UTF-8 characters in their name. > > (1.7.10 r1485443, part of TortoiseSVN 1.7.13 Win7 x64) > > > > > > I've posted the following message here > > ( http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3057388 ) > > but was suggested > > ( http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3057494 ) > > to re-address it to users subversion.apache.org : > > > > > > - > > *** THE ISSUE *** > > > > > > Workflow: > > > > 1. Create "c:\temp\UNCtest\R_UNCtest\" folder > > 2. Create a repository with default file structure in it > > 3. Checkout "trunk" dir to "c:\temp\WC\trunk" > > 4. Create file "c:\temp\WC\trunk\1‐2.txt" , > > note, that filename consists of 3 symbols, and the one in the middle is "HYPHEN" or ‐, (see > http://www.fileformat.info/info/unicode/char/2010/index.htm ) > > > > 5. Add and commit this file with Tortoise GUI. > > (this works OK) > > 6. start windows cmd > > 7. make sure your cmd is set to use UTF-8 compatible font, for example, "Consolas" (see > http://stackoverflow.com/questions/10764920/utf-16-on-cmd-exe/10765469#10765469 ). > > 8. navigate to "c:\temp\WC\trunk" > > 9. type "dir" - you should see the listing correctly, including "1‐2.txt" file > > 10. Type "mkdir 1‐2" - this should correctly create a directory. > > 11. Type "svn info 1‐2.txt" > > Result: > > -- > > svn: warning: W155010: The node 'C:\TEMP\UNCtest\WC\trunk\1?2.txt' was not found > > . > > > > svn: E29: Could not display info for all targets because some targets don't > > exist > > I believe this happens because the "chcp" command changes the OEM > (console) code-page, but Subversion uses the ANSI (Windows) code page > for input and output conversion. In other words, the "chcp" does not > affect the command-line client in any way. > > > * Am I doing something wrong? > > Not as such. :) > > > * Or could this situation be treated as a bug? > > * Or, maybe a “feature request”? > > I think the only way to actually get this right is to change the way we > read from and write to the console on Windows. Instead of converting > strings to some native encoding and using the ordinary output functions, > we should convert to UTF-16 and use wide-char output functions instead. > I'm still not sure what should I do next... Should I re-address this to d...@subversion.apache.org ? Anyway, here's a batch file, reproducing the issue: https://skydrive.live.com/redir?resid=8FD4EC3161ABA67A!916 == @echo off rem * This batch file aims to reproduce an issue with Unicode support in svn CLI. rem * This file is in UTF-8 65001 encoding, and it should not be converted to ANSI or etc. rem * I highly recommend to change default cmd font to "Consolas", for Unicode support, rem see http://stackoverflow.com/questions/10764920/utf-16-on-cmd-exe/10765469#10765469 rem * This file is based on template from rem http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs rem rem *** TESTED ON *** rem Win7 x64 - working rem WinXP x64 - not working (unable to create a file with valid name) rem 1.7.10 r1485443, part of TortoiseSVN 1.7.13 x64 rem :defineCommands rem You might need to adjust these lines to point to your rem compiled-from-source Subversion binaries, if using those: for %%i in (svn.exe) do set SVN="%%~$PATH:i" for %%i in (svnadmin.exe) do set SVNADMIN="%%~$PATH:i" :defineUrls rem Only supported access method: file://. If http:// or svn://, then rem you'll have to configure it yourself first. set URL=file:///%CD%/repos set URL=%URL:\=/% echo Base url for repo: %URL% :cleanAllDirsAndCreateRepo if exist repos rmdir /s /q repos if exist import-me rmdir /s /q import-me if exist wc rmdir /s /q wc %SVNADMIN% create repos :prepareGreekTree echo Making a Greek Tree for import... mkdir import-me mkdir import-me\trunk mkdir import-me\tags mkdir import-me\branches rem - rem HERE WE GO: chcp 65001 rem Note: Some people say, that "chcp 65001" on a line by itself aborts the batch file. rem And this seem to be true for Windows XP x64. Though, it works OK on Win7 x64. rem see http://stackoverflow.com/questions/2182568/batch-script-is-not-executed-if-chcp-was-called/2462138#2462138 rem If you're experiencing this issue, you may simply type "chcp 65001" before rem launching this script. echo This is the file '1‐2.txt'.> import-me\trunk\1‐2.txt rem Note1: The symbol between "1" and "2" is "HYPHEN" or ‐, rem see http://www.fileformat.info/info/unicode/ch
