> -----Original Message-----
> From: kmradke@rockwellcollins.com [mailto:kmradke@rockwellcollins.com]
> Sent: Friday, December 21, 2007 10:45 AM
> To: Ryan Schmidt
> Cc: 4larryj; users@subversion.tigris.org
> Subject: Re: Is CVS better for viewing commit history??
>
> 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.
The information is easy to get in other systems because each file object
is its own little microcosm. The file object microcosm has its own
history, its own branches, etc.. Essentially each file object is its
own little independent database. It's simple to implement, but pretty
inefficient. Loading the history for each separate file object in order
to merge, label, and/or get history is slooooooooooooooooooooooooow.
More importantly, the trivial information you rely on may or may not be
complete, due to Evil Twins. Evil Twins occur when you create two file
objects with the same name on different branches. In most/all systems,
there's no way to merge both files object into one object containing a
unified history.
Ex: Create branch/foo.java (which has 5 checkins and 2 branches of
history) and trunk/foo.java (which has 10 checkins and 4 branches of
history). Each is a separate file object with different histories.
When you merge branch to trunk, most systems will require you to pick
one file object or the other. So after the merge, instead of one
unified object with 15 checkins and 6 branches of history, you have to
pick one file object, thus losing the other object's history. In such a
case you'll probably keep the 10 checkins and 4 branches file object.
In short, branch/foo.java and trunk/foo.java are little independent
databases, and there's no reliable, automated way to merge databases.
So to avoid Evil Twins, you would need to create foo.java on one and
only one branch, and then merge foo.java to the other branch(es) in
order to have a complete history for the file "foo.java".
> 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.
</in_my_experience>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 21 17:48:19 2007