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 oliviera201...@gmail.com 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
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 tree of the file or directory element.
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 lesmikes...@gmail.com wrote: On Wed, Jun 12, 2013 at 2:41 PM, Olivier Antoine oliviera201...@gmail.com 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
