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
