> -----Original Message-----
> From: 4larryj [mailto:4larryj@gmail.com]
> Sent: Friday, December 21, 2007 1:15 PM
> To: users@subversion.tigris.org
> Subject: Re: Is CVS better for viewing commit history??
>
>
> I really appreciate all the discussion my post has provoked. I'm glad
> I'm
> not the only one who misses this feature. It's interesting the
> differing
> viewpoints you hear from people who
>
> -- rarely use CVS and therefore minimize the value of this feature, or
> -- use a different branching strategy , such as frequent short-lived
> branches, 1 per bug, where this feature would not be so important.
There's also a third viewpoint: most tools are moving towards a change
set paradigm. Tracking individual files is becoming less useful since
multiple files can be modified to implement a single change (you cannot
deliver or merge just one file out of the three that were changed and be
successful,) and because of inter-dependencies between changes or
features (you have to deliver feature X with middleware change Y.)
And since features/changes can be checked-in over several revisions, you
probably need to start tracking things by bug/defect/ticket number.
Since CVS/SVN's history isn't aware of bug/defect/ticket numbers, the
ability to walk the logs for individual files across branches becomes
much less important.
If your process centers around change sets, then you're probably using
bug/defect/ticket dependency checkers and a change management system.
Once you're at that point, tracking individual file history isn't
terribly useful.
> In our environment we use long-running branches, merged often to the
> trunk,
> and back into other long-running branches. There are pros and cons to
> this,
> but trust me, in this environment, the comprehensive commit history
> provided
> by CVS is imperative for keeping developers in the loop on what others
> are
> working on.
Ok, so you're using CVS to track features/defects/bugs/tickets/whatever
instead of a formal change management tool. So it's just a difference
of scale and/or data-mining. Folks who don't miss CVS's commit history
are probably relying more on the change management tool to manage the
lifecycle at a higher level.
> I'm happy and surprised that the new 'Merge Tracking' feature of
> Subversion 1.5 will include this feature. I figured all it would
> provide was a saved repository version number so the developer
> doesn't have to search the logs before performing the next merge.
> But if it provides comprehensive file history as well, then I'm a
> happy camper!
> 7. **PROBLEM** Viewing history on the trunk does not show me the
> intermediate commits made on the branch. The only commits I will see
> are those made on the trunk, and then one that says 'merged from
> Branch A to trunk'. If a developer on the branch made a commit
> comment with some vital information, I will never see it if I do
> search the history from the trunk.
>
> 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.
Err.. 1.5 won't list the intermediate commits made on the branch. It
will highlight the merge points though:
http://blogs.open.collab.net/svn/2007/06/merge_auditing_.html
http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentCo
ntainer=c2__Sample%20repository
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 23 01:27:23 2007