Full repository merge info?
Hi, I need to cache all the merges made on a repository in order to rebuild the full merge history of any item (file/directory) at any time (revision). How it can be achieved? For example, in order to cache the full history of a repository svn -log -v REPO_ROOT_URL would made the job as it returns all the revisions and their changed paths (added, modified...). With such info is feasible to build the history of any item as TortoiseSVN does for revision graphs. it would be possible get the same for merging by adding -g to the command above? Thanks, Pablo
Understanding merge info (I)
Hi, In the revision r3337 a simple tag was created on this public repository: *svn log -r 3337:3337 http://subclipse.tigris.org/svn/subclipse http://subclipse.tigris.org/svn/subclipse --username guest* r3337 | markphip | 2007-09-15 01:25:57 +0200 (Sat, 15 Sep 2007) | 1 line Create tag for 1.3.2 However, if the -g parameter is added to the command line: *svn log -g --stop-on-copy -r 3337:3337 http://subclipse.tigris.org/svn/subclipse http://subclipse.tigris.org/svn/subclipse --username guest* it returns a lot more of records saying *Merged via: r3337* For instance: r5 | cchab | 2003-06-21 00:10:43 +0200 (Sat, 21 Jun 2003) | 1 line Merged via: r3337 subclipse folder created What does it mean? How is it possible create a branch in the revision N and get merges in the same N revision? Thank you, Pablo
log reporting some strange (for me) merged paths
Hi! *Introduction* *==* I've make a log against the public Apache Subversion repository to explore the 1400377 revision: svn log -v -g -r 1400377:1400377 https://asf.apache.org/repos/asf/ most of the retrieved logs have sense, but I found two cases that maybe someone might explain me: the strict log of the 1400377 (without merge info) is: r1400377 | desruisseaux | 2012-10-20 08:23:24 +0200 (Sat, 20 Oct 2012) | 1 line Changed paths: M /sis/branches/JDK6 M /sis/branches/JDK6/ide-project/NetBeans/nbproject/project.xml M /sis/branches/JDK6/pom.xml M /sis/branches/JDK6/sis-build-helper/src/main/java/org/apache/sis/internal/taglet/Module.java M /sis/branches/JDK6/sis-build-helper/src/main/java/org/apache/sis/internal/taglet/Section.java M /sis/branches/JDK6/sis-metadata/src/main/java/org/apache/sis/metadata/ModifiableMetadata.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/jaxb/IdentifierMapAdapter.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/jaxb/IdentifierMapWithSpecialCases.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/jaxb/NonMarshalledAuthority.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/util/DaemonThread.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/util/Executors.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/util/ReferenceQueueConsumer.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/internal/util/Threads.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/math/MathFunctions.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/ArgumentChecks.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Arrays.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/CharSequences.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Characters.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Classes.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/ComparisonMode.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Debug.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Exceptions.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/LenientComparable.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Numbers.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/StringBuilders.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Utilities.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/Workaround.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/BackingStoreException.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/Cache.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/CacheEntries.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/CheckedArrayList.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/CheckedHashMap.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/CheckedHashSet.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/Collections.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/WeakEntry.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/WeakHashSet.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/WeakValueHashMap.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/collection/package-info.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/logging/LoggerAdapter.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/logging/Logging.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/logging/PerformanceLevel.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/logging/package-info.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/package-info.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/resources/IndexedResourceBundle.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/resources/package-info.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/type/AbstractInternationalString.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/type/DefaultInternationalString.java M /sis/branches/JDK6/sis-utility/src/main/java/org/apache/sis/util/type/Types.java M
[no subject]
Hi!, Please, see the log below. The newer revision r333117 is older (1999) than the its ancestor r333113 (2005). I guess that someone imported an older CVS repository in the 2005 year by using the cvs2svn tool, hence the r333117 date comes from the original CVS repo . Should it be considered as a bug or as an acceptable strange use case? I'm developing a Subversion based producthttps://marketplace.atlassian.com/1211294and I would like to know the official answer. Thanks, Pablo. svn log http://svn.apache.org/repos/asf/xalan/java@333117 r333117 | (no author) | 1999-11-09 17:50:01 +0100 (Tue, 09 Nov 1999) | 1 line New repository initialized by cvs2svn. r333113 | bayard | 2005-11-13 21:29:12 +0100 (Sun, 13 Nov 2005) | 1 line preparing migration
Apache SVN Repo upgrade to 1.7.0?
Hi, Maybe this email should be addressed to Apache Infraestructure, but... I've seen that public Apache's SVN Repository http://svn.apache.org/repos/asf/is still using the 1.6.17 version. As 1.7.0 has just been released, when is it scheduled upgrade it? Thanks! Pablo www.docminer.com
Re: Apache SVN Repo upgrade to 1.7.0?
But the bottom of the page displays this message: *Powered by Subversionhttp://subversion.tigris.org/version 1.6.17 (r1128011). * Is it normal? 2011/10/11 Hyrum K Wright hyrum.wri...@wandisco.com On Tue, Oct 11, 2011 at 2:28 PM, Pablo Beltran pbeltr...@gmail.com wrote: Hi, Maybe this email should be addressed to Apache Infraestructure, but... I've seen that public Apache's SVN Repository is still using the 1.6.17 version. As 1.7.0 has just been released, when is it scheduled upgrade it? The public Apache SVN repository has been running some flavor of the 1.7.0 release candidates for several weeks. It is currently running 1.7.0-rc4, which is identical (save name only) to 1.7.0. (And yes, these mails are probably more appropriately directed toward the infrastructure group.) Best, -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: Apache SVN Repo upgrade to 1.7.0?
I see 1.6.17 instead of 1.7.0-rc4 when I open your link. The top of the page displays: asf - Revision 1181996: /subversion/trunk/subversionand the bottom: *Powered by Subversion http://subversion.tigris.org/ version 1.6.17 (r1128011). * I've cleaned the cache of my browser and still see 1.6.17 at the bottom. And of course, both revisions (top and bottom) are different. 2011/10/11 Dave Huang k...@azeotrope.org On 10/11/2011 1:03 PM, Pablo Beltran wrote: But the bottom of the page displays this message: Powered by Subversion http://subversion.tigris.org/** version 1.6.17 (r1128011). Which page is that? The bottom of http://svn.apache.org/repos/** asf/subversion/trunk/**subversion/http://svn.apache.org/repos/asf/subversion/trunk/subversion/says, Powered by Apache Subversion http://subversion.apache.org/** version 1.7.0-rc4 (Release Candidate 4).
Re: Apache SVN Repo upgrade to 1.7.0?
When I ping svn.apache.org from: Freemont (USA): 140.211.11.4 Madrid (EU): 192.87.106.227 - This is displaying 1.6.17 Thank you! 2011/10/11 Daniel Shahaf d...@daniel.shahaf.name Dave Huang wrote on Tue, Oct 11, 2011 at 13:09:39 -0500: On 10/11/2011 1:03 PM, Pablo Beltran wrote: But the bottom of the page displays this message: Powered by Subversion http://subversion.tigris.org/ version 1.6.17 (r1128011). Which page is that? The bottom of http://svn.apache.org/repos/asf/subversion/trunk/subversion/ says, Powered by Apache Subversion http://subversion.apache.org/ version 1.7.0-rc4 (Release Candidate 4). The US master runs 1.7.0-rc4. The EU mirror runs 1.6.17 and will be upgraded soon.
Re: Modifying commit messages
Where is the bug file versioned? I think that is the point. In my opinion it should not be versioned across branches because that would be a headache. Hence it should not be placed under the trunk and you might create a new directory bugs at the same level that trunk, tags and branches. In that way, you will not create new versions of the bug file every time the trunk is copied. In your example, the content of the file (.../project z/bugs/list.txt ) would be: . BZ123: 100 . all the time (until other bug is found and the bug list is updated) You would get these results after executing the script: bug_finder.sh A (- Nothing) bug_finder.sh B (- Found bug BZ123 at r100) bug_finder.sh C (- Found bug BZ123 at r100) bug_finder.sh D (- Found bug BZ123 at r100) (This is the branch created at r125) That would happen because the r100 belongs to the log of B,C and D but not A. Normally, you would use the HEAD revision of the bug file. But you have also the history of your bugs (log of the bug file) what might be very helpful. On Fri, Jan 14, 2011 at 10:26 AM, Jonathan Oulds jonathan_ou...@mcafee.comwrote: Thank you for your response, The problem with keeping a versioned list of bugs in a file is that it only allows you to update the list in the revision that relates to the day you found the bug, and not the day you caused the bug. Example: The head of /trunk is at revision 500, I have three branches A, B and C taken from revisions 50, 100 and 150 respectively of the trunk. Now during testing I discover a bug BZ123 that was introduced at revision 100 so I update the bug list file in branches B and C; this works fine until I decide to create another branch from revision 125, BZ123 is not in my bug list text file at revision 125 so I would need to examine the head bug list file and copy across the bug numbers that are relevant. I'm not saying your system will not work, but when you take into account, merging and reverting etc. it all becomes a headache for the maintainer. I did initially consider a simple text file but rejected it for the above reasons. Please let me know if I've misunderstood your suggestion. After all I'm looking for the simplest solution. Jonathan. On 13/01/2011 18:20, Pablo Beltran wrote: I think it will work but you don't need to change the commit message to achieve that. You can create a plain text file (bug list) and versioning it in Subversion. For example, you may use this simple format: ... bug x: r1, r2, r3 bug y: r2, r7 . and look for revision numbers in the list instead of bug names. Example: does bug x appears in branch y? It's the same that checking whether any revision number retrieved from /svn log branch y /is present in the record for the bug x (r1,r2 or r3 in the example). I think that writing that script is also quite simple and the solution more maintainable and traceable. I think (not sure) that changing commit messages is out of version control scope and you would loss traceability with your solution: today you may think that bug x was introduced in r1 and appears in branch y. Next week, you might discover that bug x was really introduced in r2 and then appears in branch z but not in branch y. Sou you should change again the comment for r1 to reflect that really it was not the introduction of the bug. If you forget do it, surely next moth you will try to fix a bug on branch y which was not affected by the bug. I have another question. Would you need to answer where does bug x appears? Pablo. On Thu, Jan 13, 2011 at 5:46 PM, Jonathan Oulds jonathan_ou...@mcafee.com mailto:jonathan_ou...@mcafee.com wrote: Hello, Currently we track bug fixes by including a reference number within the commit message, I'm sure this is common practice. However we would also like to keep track of the revision where bugs were introduced. As a use case, consider a project with many branches and tags, now imagine that a bug is discovered to have been introduced at an early stage of the project e.g. revision 100. All branches taken after revision 100 will potentially have the bug all branches taken prior to revision 100 will not. The problem here is that as the number of bugs and branches increase the job of answering the question does bug x appear in branch y? becomes ever more difficult. As a possible solution we are considering modifying commit messages to indicate the bugs introduced in each revision. It should then be possible to answer the above question with a simple svn log + grep. I would be interested to hear any feedback the community has on this. Jonathan Oulds
Re: Viewing Subversion in 3D (without glasses)
LABELS might add a new dimension to Subversion: (2D - 3D) http://www.svnflash.com/images/svnflash/subversion_3d.gif I've used Jira issues instead of LABELS because I think that people will better understand the example more easily. Subversion is a very good tool for SCM (Software Configuration Management) but not so much for SCCM (Software Change and Configuration Management). http://www.svnflash.com/index.php/component/ccboard/view-postlist/forum-4-svnflash-for-jira/topic-19-is-subversion-the-sole-lider That is mainly because many things happens BEFORE Subversion revisions are created. For example, when a bug is detected there is not a revision to be related until the bug is fixed in Subversion. In other words, the top level of a change in Subversion is a revision number. But Subversion does not provides a more abstract entity to relate revision numbers. That is a lack from a Change Management point of view because many times a change affects more than one Subversion revision. So that relationships are actually managed out of the Subversion scope at the present. If you have a look at the Apache's Jira tracker then you can see how revisions are related with Jira issues by including the issue key in the Subversion commit message. This is the most used way to relate revisions with 3rd party tools. And this is a quite poor integration because: * human mistakes are difficult to fix. * changes may become un-coherent because they can not be included in an ACID transaction (one happens in Subversion and other happens in a 3rd party tool). * The concept of the change (bug, task,..) resides out of Subversion scope. Therefore developers must work on two systems to maintain the coherence of a change. This could be improved by including LABELS in Subversion. For example by creating a new command: svnlabel. Example: *svnlabel create my bug #1* And including support for labels in the current svn commands: Example: *svn commit . -m Some comment -label my bug #1* (to relate the revision and the label within a transaction) Asking for a label relationships/history: Example: *svnlabel -display my bug #1* (to display revisions related with the label) Developers should be able to relate/un-relate labels and revisions: Example: *svnlabel -add my bug #1 rN, rM* (to relate revisions N and M with the label). That sort of functionality Subversion would improve Subversion as SCCM tool. Tracker tools could create labels in Subversion (using the API) and relate issues with Subversion labels instead of revision numbers. On the other hand, developers could manage changes from Subversion by relating/unrealting revisions with labels without needing a 3rd party tool for that. Of course, a tracker would be also a very good option to manage processes/workflows, schedule, reporting, and so on. Pablo. On Tue, Jan 11, 2011 at 10:26 AM, Pablo Beltran pa...@svnflash.com wrote: That sort of information can be represented in the current 2D Subversion space as the line between two points: Example: http://www.svnflash.com/images/svnflash/branch_is_2d.png If the */a/b* item at the *N+2* revision is replaced (could be also copied or merged) with the previous content of the */a/c* item that produces a line on the same plane surface: */a/c@(N+1)-/a/b@(N+2)* In general, any information which can be represented as a group of points of type *path@revision* can be represented as a curve belonging to a 2D plane surface. In other words: (path, revision) is a vector on the 2D space. So a 3rd coordinate/concept (path, revision, ?) should be needed in order to get a 3D space. On Tue, Jan 11, 2011 at 4:47 AM, Nick nos...@codesniffer.com wrote: On Mon, 2011-01-10 at 18:46 +0100, Pablo Beltran wrote: Hi, Subversion tracks the evolution of a tree structure along the time. Changes can be represented in a bi-dimensional system coordinates: time vs space. The vertical coordinate (space) is the path of the items of the tree structure and the horizontal coordinate (time) is the revision number. Example: http://www.svnflash.com/images/svnflash/subversion_3d.png Changes of the tree structure along the time can be represented as dots (red in the example) in that system coordinates. Has some sense adding a 3rd coordinate meaning something unknown for me at the present? Thanks and sorry for so abstract question. What about using the 3rd axis to show branches and/or merges? Nick
Re: Re: Viewing Subversion in 3D (without glasses)
Hola, I think the problem is we are using the same words with a different criteria. So let me clarify with a real example. Below is a link to a real Apache's tracker issue: DERBY-4857 https://issues.apache.org/jira/browse/DERBY-4857?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel You are speaking about the Affects Version/s: field defined at the top of the page with has the value: 10.7.11 and it corresponds with this tag: http://svn.apache.org/repos/asf/db/derby/code/tags/10.7.1.1 created at the revision number: 1.049.172 I understand you when you say that there is a revision (release) before the issue, therefore an issue can always be related with a revision/release/tag On the other hand, I'm speaking about the Subversion commits panel/tab at the bottom of the same page. When a developer commits a revision then he must type the issue key in the comment in order to relate both. In this case the issue DERBY-4857 is related with this revisions: 1027056, 1027878, 1027882, 1030383 and 1030471. Relationships between issues and releases/tags are well supported by Subversion because the concept Release in a tracker can be directly related with a tag in Subversion. Depending of your needs, tracking revisions only at the release level may be enough. But for big products with a long life and with many developer working at the same time on them might be very useful also relate Subversion revisions with a more detailed concepts (issues). These last sort of relationships are not well supported by Subversion, so all the job is done at the tracker side (the Jira Subversion plugin in this case). Concepts like bug, task, requirement cannot directly be related with any Subversion concept. Thus, I think that a flexible concept like label able to be related with revisions would improve Subversion as SCCM tool. Regarding my exact words mentioned in your mail, I think they are a bit confusing. But the meaning should be what I've just explained above. On Thu, Jan 13, 2011 at 3:07 PM, Ignacio G. T. igtorque.rem...@evomer.yahoo.es wrote: Hola, Pablo. El 20:59, Pablo Beltran escribió: [...] That is mainly because many things happens BEFORE Subversion revisions are created. For example, when a bug is detected there is not a revision to be related until the bug is fixed in Subversion. [...] I'm afraid I don't understand you. When we release software, we can identify it with a version name, which we link to a specific subdirectory in the version directory of the repository, which is, in turn, related to a unique svn revision number. All the bugs that our clients report (very few :-) are traced to a specific version, so there is a unique svn revision number related to that bug. Of course, the bug may have contaminated other versions until it was detected, but there IS at least a number although the bug is not fixed yet.
Re: Modifying commit messages
I think it will work but you don't need to change the commit message to achieve that. You can create a plain text file (bug list) and versioning it in Subversion. For example, you may use this simple format: ... bug x: r1, r2, r3 bug y: r2, r7 . and look for revision numbers in the list instead of bug names. Example: does bug x appears in branch y? It's the same that checking whether any revision number retrieved from *svn log branch y *is present in the record for the bug x (r1,r2 or r3 in the example). I think that writing that script is also quite simple and the solution more maintainable and traceable. I think (not sure) that changing commit messages is out of version control scope and you would loss traceability with your solution: today you may think that bug x was introduced in r1 and appears in branch y. Next week, you might discover that bug x was really introduced in r2 and then appears in branch z but not in branch y. Sou you should change again the comment for r1 to reflect that really it was not the introduction of the bug. If you forget do it, surely next moth you will try to fix a bug on branch y which was not affected by the bug. I have another question. Would you need to answer where does bug x appears? Pablo. On Thu, Jan 13, 2011 at 5:46 PM, Jonathan Oulds jonathan_ou...@mcafee.comwrote: Hello, Currently we track bug fixes by including a reference number within the commit message, I'm sure this is common practice. However we would also like to keep track of the revision where bugs were introduced. As a use case, consider a project with many branches and tags, now imagine that a bug is discovered to have been introduced at an early stage of the project e.g. revision 100. All branches taken after revision 100 will potentially have the bug all branches taken prior to revision 100 will not. The problem here is that as the number of bugs and branches increase the job of answering the question does bug x appear in branch y? becomes ever more difficult. As a possible solution we are considering modifying commit messages to indicate the bugs introduced in each revision. It should then be possible to answer the above question with a simple svn log + grep. I would be interested to hear any feedback the community has on this. Jonathan Oulds
Viewing Subversion in 3D (without glasses)
Hi, Subversion tracks the evolution of a tree structure along the time. Changes can be represented in a bi-dimensional system coordinates: time vs space. The vertical coordinate (space) is the path of the items of the tree structure and the horizontal coordinate (time) is the revision number. Example: http://www.svnflash.com/images/svnflash/subversion_3d.png Changes of the tree structure along the time can be represented as dots (red in the example) in that system coordinates. Has some sense adding a 3rd coordinate meaning something unknown for me at the present? Thanks and sorry for so abstract question.
Re: Revisions being involved while comparing branches
On Wed, Dec 22, 2010 at 1:25 AM, Daniel Shahaf d...@daniel.shahaf.namewrote: Pablo Beltran wrote on Tue, Dec 21, 2010 at 23:29:23 +0100: Maybe the point is efficiency. OK. the *svn log -v* output for a revision range could be represented by a matrix with the revision numbers as rows and the changed paths as columns. So, for each revision is easy inquire the revised paths. That is simple because all the results are retrieved from one execution. But, how does efficiently transpose the matrix? - paths as rows and revisions as columns? and do it for the same set of values? In other words, how does one compute for a set of paths which revisions touched each of the paths? For example, when two *tags* are compared with TortoiseSVN the result is a list of revised paths. But revisions are missing from that view. That is because TortoiseSVN dispalys the *svn diff -summarize* results. So, how to display also the involved revisions for each path? The *svn info* displays only the last revision and not all involved so you should execute the *svn log* command for each revised path. And that is not efficient. You could use the #2 syntax of 'svn log': % $svn h log | head log: Show the log messages for a set of revision(s) and/or path(s). usage: 1. log [pat...@rev] 2. log u...@rev] [PATH...] I'm not sure offhand at what layer the looping on paths is implemented, though; but I hope it's done server-side. The goal is adding the involved revisions on the compare directories view of TortoiseSVN and do it in the most efficient way. Solving the problem for the most general case of comparing any two directories is a hard problem. I have solved it. Of course, I'm not a Subversion developer so I've used an external tool for that. As it is 100% free tool I think there is not problem announcing it at this mailing list. Screenshot: http://www.svnflash.com/components/com_ccboard/assets/uploads/62_9fa26b27449d15c07a49fc884484b5d1.jpg At the web site (http://www.svnflash.com), there is also a Live Demo publishing the Apache's Subversion repository at real time, so everybody can see how it works. For example, you can compare the future 1.7 release (trunk?) with the latest 1.6.15 release (tag) of the Subversion project and get the revisions for any changed path. Tip: Right click on any revision to see available commands (view, compare, blame, revision graph,...) HTH, Daniel On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: 'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies) 'dig the logs' is lookup the copyfrom revisions of the tags, and run log on replay.c for that revision range. What's wrong with that? Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100: Is there a direct way (via cmd line) to find out the revisions involved in the summary result of differencing two branches? An easy example: svn diff http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize M http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c The two tags were created in r1036188 and r1038150, but the replay.c file was modified in http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005 Is there anyway to find out the 1037005 revision number without having to analyze the logs?
Re: Revisions being involved while comparing branches
That would be a more efficient way to a achieve it but as you say that might not work in all cases. In my opinion a feature like that is enough important to be provided by Subversion via cmd line / API, because that is the one of the bridges between Subversion and Change Management tools (like Jira and others) to build SCCM baselines. Compare two tags in Subversion - get all involved revisions in that - get issues related with those revisions - get easily the changes (issues) involved between two product versions Now that is also possible to achieve but it requires a lot of previous extra computing on the Subversion side. On Wed, Dec 22, 2010 at 1:25 AM, Daniel Shahaf d...@daniel.shahaf.namewrote: Pablo Beltran wrote on Tue, Dec 21, 2010 at 23:29:23 +0100: Maybe the point is efficiency. OK. the *svn log -v* output for a revision range could be represented by a matrix with the revision numbers as rows and the changed paths as columns. So, for each revision is easy inquire the revised paths. That is simple because all the results are retrieved from one execution. But, how does efficiently transpose the matrix? - paths as rows and revisions as columns? and do it for the same set of values? In other words, how does one compute for a set of paths which revisions touched each of the paths? yes! For example, when two *tags* are compared with TortoiseSVN the result is a list of revised paths. But revisions are missing from that view. That is because TortoiseSVN dispalys the *svn diff -summarize* results. So, how to display also the involved revisions for each path? The *svn info* displays only the last revision and not all involved so you should execute the *svn log* command for each revised path. And that is not efficient. You could use the #2 syntax of 'svn log': % $svn h log | head log: Show the log messages for a set of revision(s) and/or path(s). usage: 1. log [pat...@rev] 2. log u...@rev] [PATH...] I'm not sure offhand at what layer the looping on paths is implemented, though; but I hope it's done server-side. The goal is adding the involved revisions on the compare directories view of TortoiseSVN and do it in the most efficient way. Solving the problem for the most general case of comparing any two directories is a hard problem. HTH, Daniel On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: 'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies) 'dig the logs' is lookup the copyfrom revisions of the tags, and run log on replay.c for that revision range. What's wrong with that? Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100: Is there a direct way (via cmd line) to find out the revisions involved in the summary result of differencing two branches? An easy example: svn diff http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize M http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c The two tags were created in r1036188 and r1038150, but the replay.c file was modified in http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005 Is there anyway to find out the 1037005 revision number without having to analyze the logs?
Re: Revisions being involved while comparing branches
Maybe the point is efficiency. the *svn log -v* output for a revision range could be represented by a matrix with the revision numbers as rows and the changed paths as columns. So, for each revision is easy inquire the revised paths. That is simple because all the results are retrieved from one execution. But, how does efficiently transpose the matrix? - paths as rows and revisions as columns? and do it for the same set of values? For example, when two *tags* are compared with TortoiseSVN the result is a list of revised paths. But revisions are missing from that view. That is because TortoiseSVN dispalys the *svn diff -summarize* results. So, how to display also the involved revisions for each path? The *svn info* displays only the last revision and not all involved so you should execute the *svn log* command for each revised path. And that is not efficient. The goal is adding the involved revisions on the compare directories view of TortoiseSVN and do it in the most efficient way. On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: 'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies) 'dig the logs' is lookup the copyfrom revisions of the tags, and run log on replay.c for that revision range. What's wrong with that? Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100: Is there a direct way (via cmd line) to find out the revisions involved in the summary result of differencing two branches? An easy example: svn diff http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize M http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c The two tags were created in r1036188 and r1038150, but the replay.c file was modified in http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005 Is there anyway to find out the 1037005 revision number without having to analyze the logs?
Revisions being involved while comparing branches
Is there a direct way (via cmd line) to find out the revisions involved in the summary result of differencing two branches? An easy example: svn diff http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize M http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c The two tags were created in r1036188 and r1038150, but the replay.c file was modified in http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005 Is there anyway to find out the 1037005 revision number without having to analyze the logs?
Revision graphs, MS Office documents and more
Hi!, SVNFlash is an amazing web application to explore Subversion repositories. And it is FREE. We have deployed it on our new public server in California (USA) and cached some repositories, including Apache's. Click here to start explore Apache's repositoryhttp://www.svnflash.com/index.php/apache-repository-demo. More than 1 million of revisions. Synchronized every 10 seconds. It provides revision graphs, can display MS Office, OpenOffice, PDF (etc) documents on your browser without 3rd party programs, and much more. If you like it then download the WAR file and deploy it in your Tomcat compatible application server. Open the config.html page. Register your repositories. Wait until they are cached. Include a link in your web/intranet site to embed it. That is all! Enjoy it! Pablo http://www.svnflash.com
Useful link
Hi all, Share Subversion revision graphs. Example: http://173.255.210.14/svnflash/?action=graphcss=MacOS9repo=apachepath=/db/derby/code/trunk/STATUS First time, it could take a while to load. Next times the application will be loaded from your browser cache very fast. Apache's repository is public, so you do not need to type your credentials. Simple, click on the OK button to login. After the graph is loaded click on the Tortoise button. It will display Jira issues on the graph. It will very useful for projects using a tracker. Drag the graph with your mouse and zoom in/out it while dragging it and the left Ctrl key is pressed. You can view any Apache's revision graph by changing the path parameter in the above url. Enjoy it. Pablo http://www.svnfash.com
Re: Author Flash-Subversion Books - Packt Publishing.
An idea for a very very advanced writers of Flash/Subversion books: Porting Subversion libraries from C to AS3 using Alchemyhttp://labs.adobe.com/technologies/alchemy/. So a full native client could be written using Adobe's AIR and accessing to Subversion Servers directly from inside the Flash player. Pablo. www.svnflash.com 2010/5/13 Kshipra Singh kship...@packtpub.com Hi All, I represent Packt Publishing, the publishers of computer related books. Packt is planning to expand its catalogue of Flash books and is currently inviting people interested in writing them. This doesn't require any previous writing experience. All that we require from our authors is a good knowledge of their subject, a passion to share it with others and ability to communicate clearly in English. This is a contract position and can be easily handled remotely. So, if you have an experience of integrating Flash and Subversion think that there's a book in it, here's an opportunityto write it! Contact us with your Flash and Subversion book ideas at aut...@packtpub.com. Even if you don't have a book idea and are simply interested in writing a book, we are keen to talk to you. More details about the opportunity can be found at: http://authors.packtpub.com/content/flash-experts-invited-write-Packt-books Thanks Kshipra Singh Author Relationship Manager Packt Publishing www.PacktPub.com Skype: kshiprasingh15 Twitter: http://twitter.com/packtauthors Interested in becoming an author? Visit http://authors.packtpub.com for all the information you need about writing for Packt.
Regexp for parsing urls
Hi, Do you know a regexp to validate Subversion urls? I've written one quite basic /^(svn|file|http|https):\/\/\w+(:[0-9]+)?(\/\w*)*/ but it doesn't work for all cases. Pablo.
Re: Is there a simple log/diff frontend (like gitk)?
If you mean web front end then try www.svnflash.com. It's not open source but it's free for non-profit or open source projects. The major advantages of SVNFlash are its awesome user interface and revision graphs (whole history) of files and projects. Look at the live demo and explore the Apache Repository at real time: http://svnflash.com/index.php/live-demo Pablo. 2010/4/13 Thomas Allen thomasmal...@gmail.com Hello everyone, One thing that I took for granted when doing all of my development in Git was the always-reliable gitk which provides cross-platform log and diff browsing. I'm sure it does more, but those were the main things I used it for. I am now working with a Subversion repository. Maybe I have not yet mastered the log command, but I find the output of the following two commands to be confusing: $ svn log -r HEAD r3617 | tallen | 2010-04-12 15:57:35 -0400 (Mon, 12 Apr 2010) | 1 line full comments + jslint fixes $ svn log | grep tallen # outputs nothing In general it would be very nice to have a tool to facilitate browsing recent revisions and their diffs; I do not need it to help with committing my changes or anything along those lines. So, does anybody know of a simple, cross-platform, open-source Subversion browser? I am on a Mac, and it seems that the only options are proprietary and heavy, such as Versions and CornerStone... Thomas Allen
