info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs update; merge


From: R Bresner
Subject: Re: cvs update; merge
Date: Wed, 29 Aug 2001 14:21:11 +0100

Howdy Jimm, 

What exactly are you typing to get that to happen? 
Are you using the update -C option?
Are you getting any errors or warnings during the update?

The documented default behavior is correct, something odd 
is happening that you haven't mentioned.

I don't know tkdiff at all, so I don't know if it's relevent.
However, if you haven't yet learned of the magic that is Emacs,
let me introduce you to M-x ediff-revision, which allows you to
diff a local file against a repository file, without modifying
the local file. (It will also create a temp file in the local dir.)

Cha cha cha

Jimm Grimm wrote:
> 
> Hi!
> 
>         First I want to say that CVS is way cool, and thank you all
> for your
> hard work.  But of course, I wouldn't be writing this if I didn't have
> 
> something to complain about...  ;-)
> 
>         In cvs.pdf it says:
> > For instance, imagine that you checked out revision 1.4 and started
> editing it.
> > In the meantime someone else committed revision 1.5, and shortly
> after
> that
> > revision 1.6. If you run update on the file now, CVS will
> incorporate all
> > changes between revision 1.4 and 1.6 into your file.
>         (2 October 2000 using texi2html 1.56k)
> 
>         This sounds like cvs will automatically attempt to merge the
> changes.  But instead, it just replaces the copy in my working
> directory
> with, for your example, revision 1.6.  My version gets moved to a temp
> file
> named .#name.version.  If this is all its going to do, we would never
> get
> the
> <<<<< file1
> stuff1
> =======
> stuff2
> >>>>> file2
> annotations mentioned in cvs.pdf.  This type of annotation is what I
> was
> expecting - essentially it would automatically attempt the merge, and
> provide a temp file somewhere for a 3-way diff.  I do hope this would
> be
> done via temp files - I want to be able to preview the 3-way merge
> before I
> accept it, because cvs doesn't understand C, matlab, etc.  I don't
> think
> it's a good idea to have cvs directly edit the user's file in the
> working
> directory.  I would like to preview the changes any time two users
> changed
> the same file, regardless of whether they both edited the same lines
> or not.
> 
>         But anyway, enough with my personal preferences!  Right now,
> it
> doesn't seem to be doing anything towards a merge - it just moves my
> version
> to a temp file and replaces it with the other user's version.  I get
> this
> same behavior both in windows 2000 and in linux.  Am I seeing this
> correctly?  If so, do you have any plans to incorporate auto-merging
> and 3
> way diff into cvs soon?  Or if it's there already, what am I doing
> wrong?
> How will the gui (I'm using tkdiff) know where the temp files are so
> it can
> display the 3 way diff properly?  Note that a lot of times tkdiff
> fails to
> see there's even a conflict, but I guess that is a problem I need to
> send to
> a different mailing list...
> 
> Thanks a lot!
> 
> Jimm
> __________________________________________
> Jimm Grimm, Ph.D.       address@hidden
> Senior Technical Staff                       3G W-CDMA
> Wiscom Technologies                      732/340-1540
> __________________________________________
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> © 2001 OpenLink Financial
> 
> Copyright in this message and any attachments remains with us.  It is
> confidential and may be legally privileged.   If this message is not
> intended for you it must not be read, copied or used by you or
> disclosed to anyone else.   Please advise the sender immediately if
> you have received this message in error.
> 
> Although this message and any attachments are believed to be free of
> any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the
> recipient to ensure that it is virus free and no responsibility
> is accepted by Open Link Financial, Inc. for any loss or damage in any
> 
> way arising from its use.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]