info-cvs
[Top][All Lists]
Advanced

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

Re: Utter confusion


From: Mark D. Baushke
Subject: Re: Utter confusion
Date: Wed, 08 Dec 2004 14:42:58 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden writes:

> In a message of Wed, 08 Dec 2004 12:43:00 -0800
> Received on Wed, 08 Dec 2004 21:51:00 +0100
> 
> Mark D. Baushke <address@hidden> wrote
> to: Lemke, Michael IZ/HZA-IOR <address@hidden>
> 
> >Lemke, Michael  IZ/HZA-IOR <address@hidden> writes:
> >
> >> > The 'cvs add' will only modify your checked out tree in this case.
> >>
> >> Ok, but I first have to find all those files which aren't in my sandbox
> >> anymore.
> >
> >cvs -n update | awk '/^R / {print $2}'| xargs cvs add
> >
> 
> Thanks, that's a good way.  But can you explain this from my previous
> mail:
> 
> >
> >> 
> >> You could reverse the arguments of the merge operation as an
> >> alternative...
> >
> >Well, that's an idea, why didn't I think of it...  But still no
> >luck:
> >
> >$ cvs up -j DEVP_4 -j QP_LAST_WORKING_VERSION PATCH002.htm
> >R PATCH002.htm
> >cvs update: file PATCH002.htm exists, but has been added in revision 
> >QP_LAST_WORKING_VERSION
> >
> >and it's still not there.  
> >
> 
> 
> What does it mean?

Merges happen in a checked out tree using a three-way merge. If your
tree is 'missing' the baseline version from your tree, then cvs assumes
this was your intent and supresses doing the inverse of the merge. So,
in this case, you will need to 'cvs add' the files back into your
sandbox before you can completely restore things to the way they were
before you did the botched merge operation.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBt4Ny3x41pRYZE/gRAkalAJ48p96Ol6MWTYrb491ntKwRSzq79QCg42K8
aGskjeIzi9ISyOE/eScRzAc=
=KHgU
-----END PGP SIGNATURE-----




reply via email to

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