Ryan Schmidt <subversion-2007b@ryandesign.com> wrote on 12/21/2007
01:24:17 AM:
> On Dec 20, 2007, at 20:14, 4larryj wrote:
> [snip]
> > I cannot find a way to view a complete history on a file that includes
> > commits from ALL Branches plus trunk.
>
> Correct. I don't think there's any built-in way to do that. (You
> could probably write a complicated script to do it.)
> [snip]
> > This is a big downside, does everyone agree? In CVS all changes
> > made to a
> > file, no matter on what branch, are viewable with a single history
> > command.
>
> No, I don't think everyone agrees that this is a downside. I, for
> example, have never missed this functionality. Then again, I've also
> never really used CVS.
>
> > If I'm missing something, or if there's a workaround, please
> > correct me! I
> > love Subversion and am sticking with it, I just don't like having to
> > sacrifice something that's available in CVS.
>
> I think many people here just don't find that feature necessary.
Since most other "traditional" CM systems make this information trivially
easy to get, some places have unfortunately geared their development
process around this ability.
For example, think of a large set of code (say 2M lines) in a few
hundred directories that is customized for each of your 20 customers.
(This means you have 20 different active branches where you are
continually
merging in changes to keep up to date.)
95% of the code may be identical, but unfortunately the unique code is
sprinkled throughout the code base and the same files are not unique for
each customer.
In this case, it is very useful to be able to easily see what has
been done on other "file" branches. (Just because Subversion doesn't
track individual file versions, doesn't mean there is no need to
visualize this information.)
* Yes, you might be able to use tool preprocessor directives instead
of branches, if you are using tools that would support this.
* Yes, it would be better to move the "custom" code to a separate area
and share the remaining common code as a library, if you are using
tools that would support this.
* Yes, it would be better to have designed your code base for better
reuse/support of customization.
As much as I would like to, existing projects do not usually have the
luxury of radically changing structure or procedures, so moving to
something like Subversion can be challenging...
TortoiseSVN attempts to show some of this information with the
revision graph functionality, but since it has to do an svn log -v
on the whole repo, it can be slow.
I've been toying with some scripts to automatically populate a
secondary database with copy-to information to allow easier graphing
of this information, but it is no where near functional enough to
be useful.
I believe there is a Subversion branch that is also attempting
to save the copy-to information in the repository. This should
make it easier to visualize changes to file siblings. However,
I have no idea when/if this is scheduled to go into the main
Subversion trunk.
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.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 21 16:45:39 2007