On Wed, Jun 14, 2000 at 03:56:06PM -0500, Robert Bresner wrote:
> [mixed CVS/PVCS project (one team using each, with nightly
> merges]
>
> In my leetle mind, I imagine some Perl script running at night, which would
> (ugh) file by file pull down the latest PVCS and CVS versions, merge them,
> (this is starting to sound more and more like a mad scientist pipe dream to
> me as well) and return them to their respective repositories.
A perl script *can't* do the entire merge. Only a human can
resolve conflicts. But you're right, it could do some of the
grunt work. This would be a problem even with two disjoint CVS
repositories, by the way; this part isn't PVCS's fault.
> Politics, you see, is driving this right now, and I, being the cog, need to
> find a way to make it work, or in very lay man's terms explain to the parties
> involved exactly why and how this cannot be done.
How often do you need to synchronize? If daily, I strongly
suspect that indeed it can't be done. If weekly or less, treat
their work as third-party source, and import it onto the vendor
branch. (See "* Tracking sources:: Tracking third-party sources"
in the manual.) Synchronizing looks something like:
- They send you a snapshot of their latest and greatest
- You "cvs import" it
- You do a merge, resolve conflicts, compile, test, etc.
- You ship them what is now your latest and greatest (which
includes both teams' changes since the last synchronization)
- They merge this into their code base. How? Good question.
If PVCS provides help with this, great; if not ... that's a
concrete (ie. not merely philosophical) argument against
using it.
It might make sense to have your development on a branch as well,
and reserve the trunk for merging. But I don't know; maybe this
would cause more problems than it solves (especially, getting the
results of a merge back onto your team's branch). What do other
people think?
Tag like mad, before and after every merge. Mostly this will
seem like a waste of time and effort, especially when you're
under pressure to deliver the next snapshot -- but sooner or
later you'll be very glad you did it!
> So far I've failed, because
> I don't know enough about PVCS, and the PVCS guy doesn't know enough about CVS.
> The knowledge transfer we've had thus far tells me that PVCS is not right for
> this project at all, and the tells the PVCS guy that CVS is not right for the
> project.
Of course :-( I suspect that neither is intrinsically right or
wrong for the project per se ... but each is wrong for the other
team's development style. Not too surprising; each company will
have picked a tool that suited their way of working, or adapted
to the tool's way of working, or most likely some of each.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD
- Netcraft's "What's that site running?" service, 12-Jun-2000
