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 >> >> >> >
