Re: Merging Question

[Larry Jones]

Alexander Kamilewicz writes:
> 
> I've read all about Vendor branches in Karl Fogel's book and in the
> Cederqvist and thought I knew what I was getting in to.  However, the
> crux of my problem was that whenever I've been importing their new
> changes into a module, I _never_ get a conflict message.  This is
> important, because in most cases I _know_ a file has changed (usually
> index.htm).

You only get a conflict if two different people have modified the same
line of a file; otherwise, CVS just quietly merges the changes.  If
you're just importing code and never making any local changes, you'll
never see any conflicts.

> 8.  I rm -rf acktest
> 
> 9.  I $cvs checkout acktest
> 
> 10.  I get "page1" with "second time" and "first time" is nowhere to be
> seen.

That's to be expected -- you haven't specified any explicit version, so
you get the most recent one on the default branch (which is the vendor
branch in this case since you've never made any local changes; if you
had made local changes, it would be the trunk instead).

> 11.  And then, just to prove my fears, I go $cvs update -j vendor1
> 
> 12.  And it is still acktest/page1 with "second time" as the only line
> in the file.

Of course.  You've asked CVS to merge in the changes between vendor1 and
vendor2, but you checked out vendor2 so they're already included and
there's nothing to do.  If you want to get the previous version, you
need to use -r instead of -j.

> This worries me, of course, because while it's good that the new "sites"
> I'm receiving from Dev will now be in CVS, there appears to be a) no
> version history and b) no way of "rolling back" when it turns out that
> their new changes aren't up to snuff.

Of course there's a version history -- do ``cvs log'' on a changed file
and you'll see.

-Larry Jones

My brain is trying to kill me. -- Calvin