Re: Merging in CVS

[Kaz Kylheku]

[EMAIL PROTECTED] (Stephen Cameron) wrote in message 
news:<[EMAIL PROTECTED]>...
> On 4 Dec 2002 11:49:25 -0800, Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> [...]
> >CVS allows an existing tag to be pushed to the tip of a branch in one
> >operation (tag -F) so with this method we don't have to invoke an
> >additional time-consuming untag operation to clean out an obsolete
> >tag.
> 
> Hmm.  What about this?
> 
> bash-2.04$ ls
> CVS  foo
> bash-2.04$ cvs tag mytag
> cvs tag: Tagging .
> T foo
> bash-2.04$ rm foo
> bash-2.04$ cvs rm foo
> cvs remove: scheduling `foo' for removal
> cvs remove: use 'cvs commit' to remove this file permanently
> bash-2.04$ cvs commit -m 'removed foo'
> cvs commit: Examining .
> Removing foo;
> /home/scameron/foo/foocvs/x/foo,v  <--  foo
> new revision: delete; previous revision: 1.1
> done
> bash-2.04$ cvs tag -F mytag
> cvs tag: Tagging .
> bash-2.04$ cvs update -r mytag
> cvs update: Updating .
> U foo
> 
> The tag does not get removed from foo, 
> though you probably wanted it to be.

What's worse, rtag has the same problem, because it ignores things in
the Attic directory! Ah, the stupid Attic hack.

This problem does not occur in Meta-CVS right now, because it
currently does not support merging from the trunk; so the tags it
applies with rtag are always done with -F and -r . This does
move the tags on removed files forward to their dead revisions.

But guess what? There is a workaround for the main trunk. If you use

rtag -r HEAD -F mytag module

then it *does* push the tag forward onto the 1.2 dead revision! Only
if you don't specify a revision does it ignore the Attic files. This
is acceptable; I don't care for having the tag removed; moving it to
the dead revision is okay. If I add to Meta-CVS the support for
merging from HEAD up to a branch, then this little trick will help.

> Or did I miss something?
> 
> For moving tags I have been doing this:
> 
> cvs rtag -d mytag module
> cvs rtag mytag module 

There is also the -a option of rtag, which will remove the tag from
deleted files. I think that if you combine -a and -F, you get the
behavior you are looking for.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Kaz Kylheku]

"Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> wrote in 
message news:<[EMAIL PROTECTED]>...
> > The merge tracking in Meta-CVS is done by automating a certain logical
> > procedure involving CVS tags; it's a technique which I used to perform
> > manually. Its advantage is that it does not pollute the repository
> > with too many tags, and it requires only one global tagging operation
> > per merge!
> > A merge sequence is tracked with two tags, call them ``zero'' and
> > ``one''. Both the source and target branch names are encoded into
> > these tags. The merge operations alternate between these two tags; one
> > merge will ``rtag -F'' using the zero tag. The next merge will use the
> > one tag. Then the zero tag, and so forth.
> 
> Could you explain what the two tags are used for ?
> I don't understand who that works.  It seems to me that only the
> `commit' part of the merging procedure should make any modification
> (including adding tags).  What am I missing ?

In CVS, merges are tracked using tags which are placed into the source
branch. The tags are needed in order to identify and select the two
revisions which delimit the delta that is to be merged.

Doing this properly is important otherwise lost merges could
result---changes which were committed to a stream, but not picked up
by a merge due to a race condition or other problem. You must always
tag the tip of the source branch before merging, and then merge from
the previously tagged revision to the newly tagged revision. This way
it is not possible for someone to sneak in a change just after you
merge, but before you tag.

A few approaches are possible: for example, you can create a unique
tag each time you merge, and merge from the immediately previous
unique tag to the new one. The merge tags can be incrementally
numbered, or they can contain a time and date.

I came up with the two-tag method in order to avoid polluting the
repository with an indefinite sequence of merge tags.

Instead of inventing a new tag, the older one of the two is reused. So
one merge goes from tag-0 to tag-1, then on the next merge, tag-0 is
pushed to the tip, and the merge goes from tag-1 to tag-0. The two
tags march down the branch like a pair of feet, each stride stepping
over the next chunk to merge.

CVS allows an existing tag to be pushed to the tip of a branch in one
operation (tag -F) so with this method we don't have to invoke an
additional time-consuming untag operation to clean out an obsolete
tag.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Kaz Kylheku]

"Paul D. Smith" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> This is good, and a long way better than base CVS, but it's still
> not really what ClearCase is capable of.
> 
> ClearCase creates an entirely new piece of metadata for every merge in
> each element recording the from/to versions.  That means that in
> ClearCase you can merge individual elements alone onto multiple
> branches, you don't have to merge the entire branch at once.
> 
> Also, ClearCase's merge algorithm actually takes into account the entire
> history of the element plus merge metadata, while Meta-CVS doesn't.
> This won't matter for simple merges where Meta-CVS provides the proper
> baseline, but it matters a great deal for complex merges which span
> multiple branches.  For example if you have a branch A, B, and C: you
> merge from A to C, then later you merge from A to B.  Then you want to
> merge from B to C--ClearCase will realize that for some elements it can
> use a more recent base version because of the previous merge of A to C.

Some time ago I spent a while racking my brains about problems like
this; and I came up with some solutions that will probably turn into
post 1.0 features, if anything.

One thing I can do in Meta-CVS is record the ancestry of a branch. So
that if you make branch A from the trunk, and then branch B from A, I
can record the fact that A is the ``parent'' of B, and the main trunk
is the parent of A.
Now this can help in merges if someone wants to go from B directly
down to the main trunk. We can perhaps see to what extent B has
already been merged to the intermediate A, and how much of A has
already gone down to the trunk.

At the very least, it's necessary to handle the branchpoint problem:
the first merge of B to the main trunk has to include all of the A
history from the A branchpoint to the B branchpoint; it can't just
start at the B branchpoint. Meta-CVS does not do this right; if you
merge from branch B, that means from the start of branch B. Is this
truly wrong? What if B is a feature that is independent of what
happened on branch A already? Hmm. The case can be made for having it
either way: merge only the B part, or merge the A ancestry as well.

It's clear that if you allow a lot of free branching in any direction
you end up with repeated merges. Version control systems which are
designed to support ``product branches'' from the start can
incorporate algorithms to deal with that.

In CVS we are kind of stuck with the model of ``merge back to your
immediate parent''.

> I'm not trying to put down Meta-CVS in any way: I think it's a great

Your criticism is perfectly rational and correct, which is all that
matters. Now if you want to see my response to some irrational
criticism, for your amusement, take a look at:
users.footprints.net/~kaz/mcvs-criticisms.html


:)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Kaz Kylheku]

"Paul D. Smith" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> %% "Daniels, Dave F [PCS]" <[EMAIL PROTECTED]> writes:
> 
>   ddf> From my experience, technically the way CVS performs merges is
>   ddf> fine.
> 
> I hope everyone realizes that there _IS_ a significant advantage to the
> way ClearCase handles merges, over CVS: however, as described here, it
> has nothing to do with the interactive merging itself; that's a minor
> thing.
> 
> ClearCase remembers all the merges you have performed (on a per file
> basis) and this allows it to knowledgeably choose closer BASE versions
> during three-way merges.  This makes a _very material difference_ the
> quality and experience of performing ongoing merges between branches in
> ClearCase.
> 
> In CVS, you can emulate what ClearCase does but it requires a lot of
> work... it's virtually impossible to do it by hand.  Essentially you'll
> have to add a label to the FROM version of each file that is merged
> every time you do a merge between branches, then remember the different
> labels and have a way of deciding which one is the right one, then you
> can invoke CVS merge commands specifying that version as the base of the
> 3-way merge.  You'll undoubtedly have to write a tool to manage this if
> you want to get anywhere close to the same level of functionality as
> ClearCase.
> 
> 
> You might consider looking at Meta-CVS; I haven't ever used it, and
> there are no technical docs about how it's implemented on the home page
> so I can't say anything about that, but from the features section of the
> home page it seems pretty cool.

The merge tracking in Meta-CVS is done by automating a certain logical
procedure involving CVS tags; it's a technique which I used to perform
manually. Its advantage is that it does not pollute the repository
with too many tags, and it requires only one global tagging operation
per merge!

A merge sequence is tracked with two tags, call them ``zero'' and
``one''. Both the source and target branch names are encoded into
these tags. The merge operations alternate between these two tags; one
merge will ``rtag -F'' using the zero tag. The next merge will use the
one tag. Then the zero tag, and so forth.

But it's critical to remember which tag to use! When I did this
manually, I would look into the CVS history to find out which tag I
used last, and push the opposite one forward, then merge from the last
one to the opposite.

In Meta-CVS, a clever trick is used. The tag which was last used is
the one which is first in the tag list of a well-known file. And that
well-known file is MAP; every Meta-CVS project has that file.

When CVS deposits a brand new tag into an RCS file, it places it at
the top of the list. And that priority can be used to encode a one-bit
property associated with a pair of tags, such as which one of two tags
is more recent. When you update an existing tag, however, it does not
move to the top of the list! So you must delete the tag, and then
re-create it, if you want it to jump to the top.

So before the global tagging operation, what Meta-CVS does is perform
an untagging operation on the MAP file. So after the global tagging,
it is ensured that the new tag is at the top of the list in that file,
and therefore the next time we know it's *not* the one to push forward
with rtag -F.

Unfortunately, tagging operations are unreliable. We would want a
sequence of these tagging operations to be atomic, but alas, even a
single tagging operation is not.

Clueless people like to complain about the lack of atomic commits in
the CVS platform; but these are hardly a problem at all! The real
problem is the lack of atomic tagging, which is needed to correctly
support higher-level merge operations and such.

Another problem is that if two people concurrently perform the same
merge (from the same source to the same target) that is an open race
condition. The solution is not to do that, but this might be wishful
thinking. Because merging in CVS is hard, it's likely that it's done
rarely and by a dedicated person (i.e. the only one without a
sufficient life who has time to figure it all out). But if you make it
easy enough, non-experts will do it casually, and so the concurrency
problem could arise.

If you can squint your eyes at the atomicity and concurrency issues,
the software is pretty darn convenient. You just type ``mcvs merge
'' and it's done. Check, fix, commit.   If a merge goes
sour and you have to throw away your local edits, you can re-do it
using ``mcvs remerge ''.

I maintain two streams of the Meta-CVS sources now. Merging is so darn
convenient that I do it for every single commit. Commit in the branch,
switch to a sandbox that is on the trunk, ``mcvs merge
mcvs-1-0-branch'', inspect, commit.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[Paul Sander]

You will seriously miss directory versioning and the ability to reorganize
your source code at will.  Depending on your process, you might also miss
the ability to store named attributes on your artifacts.  My users also
make heavy use of the graphical version tree browser, which displays
merges.  And then there's clearmake...

--- Forwarded mail from [EMAIL PROTECTED]

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.

--- End of forwarded message from [EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Paul Sander]

There is an aspect of ClearCase that makes its merge operations significantly
superior to CVS, which is in the way it identifies the common ancestor of
of a 3-way merge.  It considers the results of past merges, not just the
intersection of the branches.  The effect is that resolved conflicts
don't reappear in subsequent merges.

One other less-often used feature is that ClearCase merges can take up to
32 contributors, so that it's possible to merge more than two branches in
one sitting.

--- Forwarded mail from [EMAIL PROTECTED]

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.

--- End of forwarded message from [EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual
>work.

>Oh, do you know of a configuration management system that can read human
>minds?=20

>Basically, two changes have been made to the *same spot*: one in your
>work area, and one checked in by someone else.  Which change should be
>kept when you update to the latest version in the repository?=20

>CVS certainly can't guess for you, so it marks it in a conflict block.
>So does every other CM system.

Well, a lot of other CM systems invoke a graphical merge program in which
the user resolves conflicts such as this.

But to answer the original poster's question:  Yes, there is a workaround.
Don't introduce conflicting changes.

>--- End of forwarded message from [EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Riechers, Matthew W]

Donald Sharp wrote:
> 
> 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.

Bitkeeper's "Free Use" BKL license 
section 3(c) prohibits development of competing SCM software, but AFAIK
the commercial license  has
no such restrictions.

-Matt


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[MacMunn, Robert]

It is looking that way to me also and you can't beat the price.  A friend of
mine was at the Apache conference this week and says there is a replacement
coming out for CVS.

-Original Message-
From: Daniels, Dave F [PCS] [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 2:43 PM
To: MacMunn, Robert
Cc: [EMAIL PROTECTED]
Subject: RE: Merging in CVS


>From my experience, technically the way CVS performs merges is fine. The
biggest problem has been misunderstanding of how to correctly perform a
merge, and this is a problem you can have with any tool. I've had instances
where someone complained that CVS screwed up a merge, but when I dug a
little deeper, it turned out the user had made the mistake, not the tool.

There are some holes in CVS (e.g., directory versioning), but overall it's a
very easy tool to use and manage, even with a large number of users.

Dave



> -Original Message-
> From: MacMunn, Robert [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 12:54 PM
> 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 o

Re: Merging in CVS

[Donald Sharp]

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 toolsmi

RE: Merging in CVS

[Greg A. Woods]

[ On Friday, November 22, 2002 at 12:23:56 (-0500), MacMunn, Robert wrote: ]
> Subject: RE: Merging in CVS
>
> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

Three-way merges can be difficult any time there are conflicts.  CVS is
no different in this than _any_ other similar tool.

You don't have to do the merges manually.  You could, for example if
you're an emacs user, use emacs ediff to re-do the merge with a nice
menu-driven button-pushing visual interface.  There are lots of other
alternative interfaces too.

-- 
Greg A. Woods

+1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[Daniels, Dave F [PCS]]

The replacement he's referring to is Subversion. I don't think it's quite
ready for prime time, but it looks like it will be very nice.

Dave

> -Original Message-
> From: MacMunn, Robert [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 1:54 PM
> To: Daniels, Dave F [PCS]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Merging in CVS
> 
> 
> It is looking that way to me also and you can't beat the 
> price.  A friend of
> mine was at the Apache conference this week and says there is 
> a replacement
> coming out for CVS.
> 
> -Original Message-
> From: Daniels, Dave F [PCS] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 2:43 PM
> To: MacMunn, Robert
> Cc: [EMAIL PROTECTED]
> Subject: RE: Merging in CVS
> 
> 
> From my experience, technically the way CVS performs merges 
> is fine. The
> biggest problem has been misunderstanding of how to correctly 
> perform a
> merge, and this is a problem you can have with any tool. I've 
> had instances
> where someone complained that CVS screwed up a merge, but when I dug a
> little deeper, it turned out the user had made the mistake, 
> not the tool.
> 
> There are some holes in CVS (e.g., directory versioning), but 
> overall it's a
> very easy tool to use and manage, even with a large number of users.
> 
> Dave
> 
> 
> 
> > -Original Message-
> > From: MacMunn, Robert [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 22, 2002 12:54 PM
> > 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:
> > &g

RE: Merging in CVS

[Daniels, Dave F [PCS]]

>From my experience, technically the way CVS performs merges is fine. The
biggest problem has been misunderstanding of how to correctly perform a
merge, and this is a problem you can have with any tool. I've had instances
where someone complained that CVS screwed up a merge, but when I dug a
little deeper, it turned out the user had made the mistake, not the tool.

There are some holes in CVS (e.g., directory versioning), but overall it's a
very easy tool to use and manage, even with a large number of users.

Dave



> -Original Message-
> From: MacMunn, Robert [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 12:54 PM
> 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: Mac

RE: Merging in CVS

[Shankar Unni]

> [ 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!)

-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 
> > fi

RE: Merging in CVS

[MacMunn, Robert]

Thanks



-Original Message-
From: Kaz Kylheku [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 1:44 PM
To: MacMunn, Robert
Cc: [EMAIL PROTECTED]
Subject: Re: Merging in CVS


On Fri, 22 Nov 2002, MacMunn, Robert wrote:

> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual
work.

You are jumping to conclusions; read the documentation and work with
CVS merges for a while. There is some manual work in merging, but it's
not in the area where you think it is; namely, it is in the logistics
of tracking what has been merged where. The actual merge algorithm does
a good amount of work for you; you will find that most changes merge
without conflicts, and that conflicts are usually easy to resolve.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[Jenn Vesperman]

On Sat, 2002-11-23 at 05:28, MacMunn, Robert wrote:
> 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.

Check the various CVS graphical clients - some of them display the
conflicts in merges in a merge tool. It sounds to me like that's what
you're after.

CVS just allows you to do the same thing in your own choice of editor.



Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.

[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Jamie Wellnitz]

Try xxdiff (http://xxdiff.sourceforge.net).  It has an option, -U,
which "unconflicts" a file.  It gives you a graphical
click-one-or-the-other display of a files with merge conflicts.  I've
found it to be quite useful.

You still have to figure out the relative value of each change, but
fixing that does seem to involve mind-reading on the part of the tool.

This mini-script goes through a sandbox and shows the conflicts in any
file that has them.

for f in $(cvs -nq update | awk '/^C /{print $2}')
do
   echo $f
   xxdiff -U $f
done

On Fri, Nov 22, 2002 at 10:38:36AM -0800, 'Thomas S. Urban' wrote:
> 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

Re: Merging in CVS

['Thomas S. Urban']

I'm curious if the feedback about how "CVS handles merges poorly" is
about the automatic merge action or the way conflicts are presented? I'm
guessing the latter.  If you'll listen to what people here are saying, I
think you'll find the answer to your question:

  - CVS and clear case both do the same things for merging (automatic if
possible, require user intervention if not)

  - if editing files to deal with conflicts is distasteful to you or
your developers, conflict resolution tools exist or can easily be
written that should please your editor-phobic developers.  I'm sure
if you look you can find a tool that matches the capabilities of the
clearcase one.

  - using this and other tools in conjunction with CVS is a matter of
policy and/or administration - it is your responsibility to show or
tell people how to use the tools, or provides scripts or commands or
other automation so it happens as appropriate


On Fri, Nov 22, 2002 at 13:53:58 -0500, MacMunn, Robert sent 5.1K bytes:
> 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-

Re: Merging in CVS

[Kaz Kylheku]

On Fri, 22 Nov 2002, MacMunn, Robert wrote:
> > 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.
> 
> Not at all.  In Clearcase you have a graphical interface where the conflicts
> can be taken care of as the merge happens.  

It's debatable whether taking care of conflicts before the entire merge 
operation is complete is a good idea compared to getting the entire
merge and then working on it.

There are graphical interfaces for merging that can be used with CVS,
if you would rather click on the left text or right text than use an
editor.

> No manual editting of files.

That is only the case when the resolution of the conflict is a trivial
choice between the left and the right version. Sometimes a conflict
must be some combination of the two, and so editing is required.

Note that you could write a trivial shell script to read a text file,
look for the <<<===>>> delimited sections and present you
with a simple menu to pick the left or the right text, or bring up a
text editor to do the edit. Then a script above that could look for the
conflicting files, and invoke the resolver on them one by one. Here is
a sketch of the main loop:

  while read line ; do
# do some tokenizing
case first_token in
  <<< )
# ... logic to start collection of left text to a temporary file
;;
  === )
# ... start collection of right text to temporary file
;;
  >>> )
# ... call user-friendly resolution menu function
;;
  * )
# write line to appropriate output file: left, right or main.
   ;;
esac
  done < file

Lastly, if you really want ClearCase, you know where you can get it! 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Eric Siegerman]

On Fri, Nov 22, 2002 at 12:23:56PM -0500, MacMunn, Robert wrote:
> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

Only when both new versions have changed the same area of the
file.  That is, if I edit line 100 and you edit line 120, there
won't be a conflict.  But if we both edit line 110, there will
be.

That's the theory.  In practice, here is a partial list of things
that can cause *lots* of conflicts:
 1. Line-ending differences:  your file has UNIX line endings;
mine has Windows line endings (as if! :-).  Then CVS will see
*every* line as different, so the whole file will be one huge
conflict.

 2. If one (or both) people reformat the code -- run it through a
code beautifier, change spaces to tabs or vice-versa, go
through by hand and nicely line up abundant end-of-line
comments, or whatever.

Even though those changes don't have any effect on the
program's behaviour, they're still changes as far as CVS is
concerned, so they'll conflict with any other change (whether
significant or also trivial) that another person makes in the
same region of the file.

 3. If someone wraps a block of code in an "if" statement, say,
they'll indent it all an extra level.  Again, the indentation
change is a non-event as far as the compiler's concerned, but
CVS can't tell that.

 4. CVS keywords, especially $Log$.

 5. Configuration files that need to be customized for each
instance of the system (different sandboxes, different
servers, etc.)  All the routine per-instance customizations
often conflict with substantive changes.

XML seems to be particularly bad for this, I suspect because
there's so much redundancy that the merge algorithm can get
confused more easily than with other file types.

Some of those situations should just be avoided:  (1); $Log$;
possibly other $Xxx$'s, though $Id$ can be useful enough to be
worth putting up with the resulting merge conflicts.

Others -- (2) and especially (3) -- are sometimes necessary, so
the trick is to do them in such a way as to minimize the pain.
If you know you're going to be making massive, trivial changes,
like beautifying the whole project, get other people to commit
their changes and go to lunch.  Then you update, do your thing,
and commit.  That way they won't have done any work, so there
won't be any conflicts.  Things like changing the indentation on
a large block of code are harder to schedule -- you do it based
on need, not on "would be an improvement" -- so the resulting
conflicts just kind have to be lived with.

(5) can be greatly improved by going to a template-based
approach.  For the project I'm currently on, I whipped something
up in Perl to do autoconf-like macro substitutions on the XML
config files.  If all the per-instance customizations -- host
names, port numbers, etc. -- are done by that Perl script, and
only the uncustomized templates are stored in CVS, the many
pointless conflicts will go away, and the only remaining
conflicts will be between groups of *substantive* changes.

A special case of (2) is files that are written with the aid of
smart tools -- XML editors, IDE's, and the like.  Then you don't
necessarily have control over the precise formatting; the tool
might change things in ways you didn't expect.  Similarly filled
text -- add a word, and the rest of the paragraph might get
reflowed.  Not much that can be done about those cases, unless
you (and your colleagues) are willing to forego the spiffy
tools...

In summary, merge conflicts are indeed a problem.  Worse in some
situations than in others, but usually manageable, by which I
mean, reducible to the level of annoyance rather than major
productivity drain.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Just Say No to the "faceless cannonfodder" stereotype.
- http://www.ainurin.net/ (an Orc site)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[david]

> 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.
>
Not in all cases.  The conflicts I've gotten have usually not been a
result of total rewrites, but of conflicting changes for one or
more functionality changes, and so they really do need to be merged
rather than simply selecting one or the other.  That's when it
gets difficult, and no tool can make it much easier.

When it is a matter of selecting one version or the other, then
with any decent text editor it should be a matter of a few
keystrokes to remove the one you want.  (If you are using an
editor where this would be a big deal, you might want to look
into changing editors.  There's no reason to work with inferior
tools when superior ones are free and available on all major
platforms.)
 
So, CVS handles most merges by itself.  It refers what it can't
resolve to the developer, who can use his or her favorite editor
to resolve the conflicts manually.  The mechanics may not be
slick, but they're reasonable enough for an operation that really
shouldn't be all that common.  Since the advantage of Clearcase
here can only be in the slickness of mechanics, it really can't
be all that great.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[MacMunn, Robert]

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 

Re: Merging in CVS

[Kaz Kylheku]

On Fri, 22 Nov 2002, MacMunn, Robert wrote:

> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

You are jumping to conclusions; read the documentation and work with
CVS merges for a while. There is some manual work in merging, but it's
not in the area where you think it is; namely, it is in the logistics
of tracking what has been merged where. The actual merge algorithm does
a good amount of work for you; you will find that most changes merge
without conflicts, and that conflicts are usually easy to resolve.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[MacMunn, Robert]

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.

-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


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

['Thomas S. Urban']

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

Re: Merging in CVS

[Larry Jones]

MacMunn, Robert writes:
> 
> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

Only when there are conflicts (i.e., the same line of code separately
modified by two different developers).  In reality, conflicts occur very
rarely.

-Larry Jones

Hello, I'm wondering if you sell kegs of dynamite. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Thomas S. Urban]

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



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

['Thomas S. Urban']

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.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[MacMunn, Robert]

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.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[Shankar Unni]

> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual
work.

Oh, do you know of a configuration management system that can read human
minds? 

Basically, two changes have been made to the *same spot*: one in your
work area, and one checked in by someone else.  Which change should be
kept when you update to the latest version in the repository? 

CVS certainly can't guess for you, so it marks it in a conflict block.
So does every other CM system.
--
Shankar.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Merging in CVS

[MacMunn, Robert]

Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

-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

Re: Merging in CVS

[Kaz Kylheku]

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

Re: Merging in CVS

[Jenn Vesperman]

On Sat, 2002-11-23 at 03:35, 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 ?

This means that the same lines were changed in the two files, and CVS
doesn't know which lines the humans want put where. It's called a
'conflict', and it requires human intervention.

> <<< nightly_kituibuild_sol_flash_LOG_Sep27_12.36.10_151
> #
> #
> #
> ===
> #a
> #
> #
> >>> 1.2.2.4

,  and  were changed in the first file, and a,  and
 were changed in the second file. Both were line numbers foo, foo+1
and foo+2, so CVS couldn't just plug them in as it normally does.

The way to prevent this from happening is to ensure that noone edits the
same lines of the same revision. :) Yes, that's overly simplistic. 


If you need more help or a better explanation, ask.



Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.

[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging in CVS

[Nick Patavalis]

On Fri, Nov 22, 2002 at 11:35:17AM -0500, MacMunn, Robert wrote:
> 
> When I merged 2 files I got extra lines teling me where the merged lines
> where.
> Is there any way around this ?

The extra lines with  and > appear only when there are
conflicts in the merged files. They are a feature, not a bug, since
they indicate that CVS cannot decide, by itself, what to do. You have
to manually edit these places.

/npat

-- 
A commune is where people join together to share their lack of wealth.
  -- Richard M. Stallman


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs