"Reedick, Andrew" <jr9445@ATT.COM> wrote on 12/21/2007 10:47:18 AM:
[I'm not trying to poison any discussion here, but I do think the
original statement that few would find this type of information
useful was incorrect. We all come from different use cases.]
> > Since most other "traditional" CM systems make this information
> > trivially
> > easy to get, some places have unfortunately geared their development
> > process around this ability.
>
> <in_my_experience>
>
> The information is trivial because it's a side effect, not a design
> feature.
Just because it is a side effect, doesn't make it "bad". Now that
Subversion has matured past some of it's original design goals, I think
it is useful to revisit some of these (unavailable) features again.
I am not suggesting to re-implement the current design to make this
information trivial to get, but to potentially provide a way to
gather this type of information from the current system and provide
it to the user in an easy to get fashion. This is why I'm exploring
tying some hook scripts into a secondary database to generate the
information I am seeking. Sorta like what was done with merge tracking
originally.
I suppose in a small way, I'm trying to gather requirements for how
others would like to be able to better visualize file history, since
I realize I haven't experienced all development techniques.
[snip of evil twin example]
Evil twins only occur when the file name is considered the only unique
part of the file, and ignoring parentage, etc. It is something
that definitely needs consideration in any design.
> > In this case, it is very useful to be able to easily see what has
> > been done on other "file" branches.
>
> Can't see the forest for the trees. Your change management system
> should be able to tell you what was done to each branch. Which normally
> means being able to have a master defect/bug/ticket and creating one
> child defect/bug/ticket per branch in order to ensure the work is done
> and tested on each branch.
>
> The information you want to track can't be easily or reliably tracked by
> any version control system. You need a real Change Management system
> tied into your source code control system.
And we do use Change Management software as well. I disagree that
some additional visualization of file history is unreliable and
this information should only be available in a Change Management system.
> > The merge tracking support in 1.5 will help with the merge
> > process between 2 branches, but I'm not sure it will be
> > overly helpful in visualizing sibling changes between
> > multiple branches.
>
> It looks like 1.5 'svn log' will have the ability to walk into merges.
> I think it was described in one of the blogs:
> http://merge-tracking.open.collab.net/servlets/ProjectProcess?tab=2
I have been following and testing the merge-tracking stuff, and it
wasn't really meant to solve this particular problem, nor do I think
it should have been a design goal of this feature.
Merge tracking is definitely a prerequisite to any complex development
process, and any advanced file visualization will need to include
merge information, but I don't think it can replace it.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 22 10:39:09 2007