info-cvs
[Top][All Lists]
Advanced

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

RE: cvs update; merge


From: Jimm Grimm
Subject: RE: cvs update; merge
Date: Wed, 29 Aug 2001 13:42:31 -0400

Hi!

        Wow - I couldn't get tech support that fast these days even if I
paid a million dollars for the software - thanks for the quick response!
You helped me figure out why this is happening to me.  Now I just have to
figure out what to do about it...

        We work with a lot of binary as well as ASCII files (on linux and
windows), and I was too paranoid that a binary file would be mistaken as
ASCII and get mangled upon checkin.  So in cvswrappers I told it * and *.*
are binary.  The files I am now trying to merge are actually ASCII, but
since I told cvs they are binary, it isn't going to merge.  Now that I look
back, I see I was getting the "nonmergeable" message; I just didn't realize
what it meant.

        I updated my cvswrappers file to look like:
*.* -k 'b'
* -k 'b'
*.txt -m MERGE

But this doesn't seem to do any good.  In cvs.pdf, it says the -m option is
for non-binary files, so I guess I shouldn't expect this to work.

        What do you suggest I do?  We make lots of binary files (test
vectors) with all sorts of extensions, and have both win32 and linux
platforms.  It is impossible to predict what extensions will be binary or
what machines they will be on, but we sure don't want any to get messed up
if they are mistaken for ASCII.  At the same time, we do want to be able to
merge ASCII source code.

        Is there any way to get CVS to ignore CRLF conversions, yet still do
merges?  I hope I am not touching a sore spot...

Thanks!

Jimm


> -----Original Message-----
> From: R Bresner [mailto:address@hidden
> Sent: Wednesday, August 29, 2001 9:21 AM
> To: Jimm Grimm
> Cc: address@hidden
> Subject: Re: cvs update; merge
> 
> 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]