On Fri, Nov 22, 2002 at 11:16:37AM -0800, Shankar Unni wrote:
> > [ bring up files for merging as soon as the conflict is detected ]
>
> No, CVS can't do that. Fundamentally, CVS is a command-line tool, and
> all that the GUIs (like WinCVS) do is to put a pretty face on it.
>
> By the way, how ClearCase works is that in the *command-line* tool
> ("cleartool"), you have an *option* for what to do for conflicts. And in
> ClearCase, *any* situation where someone else has modified a file behind
> your back is considered a "conflict", even if the changes are in
> different parts of the file:
>
> * Abort the update if there is any conflict (even if it was
> automatically mergeable)
> * Attempt to do an automatic merge, and abort if there is (in CVS
> parlance) a conflict in the merge
> * Do the merge even if there is a (CVS-ese) conflict in the merge, and
> mark the conflicting regions with "<<<<" and ">>>>" markers (just like
> CVS does).
>
> CVS only has the last option. Perhaps it should also have the middle
> option, so that GUI tools can use that as a hook to fire up an
> interactive merging GUI (like WinMerge or Araxis Merge) with the two
> conflicting copies.
>
> In any case, there isn't a whole lot of difference in the philosophies.
> Finding files with conflicts in the merge in CVS is trivial: you can do
> a "cvs update | grep '^C'" to search for these. WinCVS shows them
> automatically in the GUI, and there's a button to only show files with
> conflicts.
>
> By the way, Perforce isn't such a bad tool either - they have a rather
> odd (to CVS and ClearCase users) branching model, but on the other hand,
> provide some really good changeset management features that CVS doesn't
> have (but ClearCase does).
>
> Another system you might want to explore is BitKeeper. Google for it.
> It's all the rage in the Linux development world these days, and the
> creator is well-known in the Linux world (Larry McVoy, the lmbench guy).
> But its distributed repository model is somewhat extreme (think
> ClearCase multi-site taken to the limit, where each user is a mirror
> site!)
Be carefull using/working with bitkeeper for those of you who do
development on any other scm system. The license prohibits you
from using bitkeeper and doing development on competitors to bitkeeper.
thanks!
doanld
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
> Of MacMunn, Robert
> Sent: Friday, November 22, 2002 10:54 AM
> To: 'Thomas S. Urban'
> Cc: [EMAIL PROTECTED]
> Subject: RE: Merging in CVS
>
>
> We have 3 CM tools within the whole comapny. CVS, Perforce, and
> Clearcase.
>
> Management wants to go with 1 tool. They feel Clearcase is too
> expensive, and it can be. I am a Clearcase guy, but know the cost. So,
> Perforce seems limited, CVS seems to be able to handle all that we need.
> I just need to make sure that there aren't any gotcha's.
>
> >From the feedback I am getting from other CVS users is that CVS handles
> merges poorly. I am not here to start an arguement on which is the
> better CM tool. I am not closed minded to think that because I know
> Clearcase, that it is the best tool. I am trying to find out where we
> may have problems with release engineering and developers. The
> graphical merge tool Clearacse has saves a lot of time, and it is part
> of Clearcase. The cost of Clearcase is just too astronomical now and
> like I said CVS seems to have all that we need. I am just trying to
> figure out what we gain and what we lose.
>
> -----Original Message-----
> From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 1:39 PM
> To: MacMunn, Robert
> Cc: [EMAIL PROTECTED]
> Subject: Re: Merging in CVS
>
>
> So use Clearcase if it provides something you can't live without. I'm
> only trying to point out that logically, the operations are the same
> (the timing may be a little different), e.g:
>
> 1 You request an update of local file to newest version in repository
> 2 CVS will merge new version and local changes (if any) automatically,
> (if possible)
> 3 If automatic merge is not possible, CVS forces user to *manually*
> resolve conflicts
>
> If you can show my how clearcase behaves differently than this
> *logically*, then maybe you've got a point (and maybe I'll start using
> clearcase since it would then have the ability to read my mind).
>
> Everthing else is just interfaces and easy of use, both of which are
> qualities easy to remedy through toolsmithing, IMO.
>
>
> On Fri, Nov 22, 2002 at 13:28:02 -0500, MacMunn, Robert sent 3.0K bytes:
> > It isn't a slick interface. In Clearcase it is the merge tool itself
> > that gives you the ability to deal with the conflicts easily.
> >
> > -----Original Message-----
> > From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 22, 2002 1:27 PM
> > To: MacMunn, Robert
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Merging in CVS
> >
> >
> > On Fri, Nov 22, 2002 at 13:17:12 -0500, MacMunn, Robert sent 1.7K
> > bytes:
> > > Not at all. In Clearcase you have a graphical interface where the
> > conflicts
> > > can be taken care of as the merge happens. No manual editting of
> > > files.
> >
> > A nice tool with a graphical interface is still a manual tool. It may
>
> > be easier to use than a simple text editor (but why would you use a
> > simple text editor?), but both process are manual versus automatic.
> > Perhaps the time the manual work happens is significant, I don't know,
> > but it still happens.
> >
> > Graphical interfaces for dealing with the conflict markers CVS
> > produces probably exist, either with one of the many GUI clients, or
> > with emacs. The vim plugin I use highlights them specially. If I
> > cared, I could write easy vim functions that would take one version or
>
> > the other for each conflict. But it rarely comes up in our usage
> > (i.e. including good communication), so I don't care all that much
> > about slick interfaces to conflict resolution.
> >
> > >
> > > -----Original Message-----
> > > From: Thomas S. Urban [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, November 22, 2002 1:16 PM
> > > To: MacMunn, Robert
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Merging in CVS
> > >
> > >
> > > On Fri, Nov 22, 2002 at 12:23:56 -0500, MacMunn, Robert sent 0.9K
> > > bytes:
> > > > Thanks. Looks like merges must be difficult in CVS. A lot of
> > > > manual
> > > work.
> > >
> > > Most of the time, merges happen automatically. Manual intervention
> > > is only required when they can't happen automatically. Conflicts
> > > always take (some amount) of a manual work. Merges never do. I
> > > don't see how you can get around this fact in any system, short of
> > > exclusivity.
> > >
> > > Looks like you may be confused by terminology. RTFM.
> > >
> > > HTH
> > > Scott
> > >
> > >
> > > >
> > > > -----Original Message-----
> > > > From: Kaz Kylheku [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, November 22, 2002 12:18 PM
> > > > To: MacMunn, Robert
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: Merging in CVS
> > > >
> > > >
> > > > On Fri, 22 Nov 2002, MacMunn, Robert wrote:
> > > >
> > > > > I am new to CVS. I am testing out merging.
> > > > >
> > > > > When I merged 2 files I got extra lines teling me where the
> > > > > merged
> > lines
> > > > > where.
> > > > > Is there any way around this ?
> > > > >
> > > > > Ex.
> > > > > The <<<<<<< and >>>>> delimit the merged lines.
> > > >
> > > > No, they delimit conflicts. You can't get around conflicts. You
> > > > must resolve them when they occur, and you can't prevent them from
> occuring,
> > > > unless people working independently magically stay out of each
> > > > other's way.
> > > >
> > > > RTFM!
> > > >
> > > >
> > > > _______________________________________________
> > > > Info-cvs mailing list
> > > > [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
> >
> > --
> > Stupidity is its own reward.
>
> --
> Building translators is good clean fun.
> -- T. Cheatham
>
>
> _______________________________________________
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
>
>
> _______________________________________________
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
