[Top][All Lists]

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

Re: CVS and multiple platforms - version conflicts, featuresavailable et

From: david
Subject: Re: CVS and multiple platforms - version conflicts, featuresavailable etc.
Date: Tue, 7 Jan 2003 17:02:26 -0600 (CST)

> I've been placed in charge of getting version control/management going
> at an organisation where I work.
> Right now, an almost anarchic situation exists where there is no real
> version control, several different versions of the same code are
> mishmashed across several machines, and there's no one true version of
> the stuff being developed.
Look on the bright side.  There are very few bad choices here.
> JSP, Java and HTML files are being generated/edited/developed under
> multiple IDEs & site management tools (DreamWeaver's in the mix too -
> which introduces some template editing issues) across multiple platforms
> (MacOS 9 and Win2K primarily).
CVS does nicely with JSP, Java, and HTML files.  The one thing
you might want to watch out for is that, if you like messing with
the package names, you'll also mess with the directory structure,
and CVS doesn't track that at all well.  If you have a stable
directory structure, that's no problem at all.
> A system where file versions can be tracked and people can be notified
> when other people are editing files etc. needs to be introduced for
> security, accountability, stability and backup purposes.
I don't see the exact security issue here.  CVS can be part of a
secure solution, but it isn't security-oriented by itself.
Similarly, there are more and less accountable ways to use CVS.
CVS will do well for stability and backup purposes.
> I understand that CVS can kinda do exclusive checkouts through what
> appears to be an RCS kludge, but that a slightly less enforced,
> user-cooperative method is available through watch, unwatch, edit and
> unedit.
In my experience, the cooperative model works just as well as strict
locking.  Cooperative developers will work just fine with the edit
facility, and uncooperative developers will subvert strict locking.
For much of what you are working on, you may find that even the
edit facility is overkill.  I've worked happily in a shop with a
few dozen developers without using any such feature.  It usually
worked well, and in the cases where it didn't I didn't see that
any sort of locking would have helped much.  The problems were
simply that the situation, and hence the solution, was messy.
> What versions of CVS include this watch/unwatch/edit/unedit
> functionality?
As far as I know, all of them that you'd remotely want to use
(IIRC, 1.10.6 was the first Y2K-compliant one, and earlier
versions will have problems when handling dates).  I haven't
seen any problems with the edit facility on them.
> Right now the server that's going to be running as the version
> management system has:
> -Debian 'stable' Linux
> -Kernel 2.4.18 w/XFS Rel 1.1
> -cvs 1.11.1p1 w/pserver (yes, it's firewalled)
> I'm working with several MacOS 9 and Win2K clients as well as a Debian
> 'unstable' Linux system (my workstation) which has cvs 1.11.2-debian on
> it.
All of which have several clients.  I am most familiar with the
WinCVS/MacCVS/gCVS clients, which as a group will run on all the
systems you've got.  This has the advantage of providing a mostly
common front end for your shop.
> Do people have some alternate suggestions for version control that
> should realistically be explored (I do realise this is kind of like
> going to a GM motor club and asking about Fords :))?
To me, it sounds like a situation where CVS would work very well.
Obviously, other solutions might be better suited, but I haven't
read a thing to discourage me on CVS.
> I've heard a lot of noise about subversion and bitkeeper and other bits
> and pieces both GPL and closed source $$$ etc.
Subversion looks like it's going to be great when it's done, but
last I looked it wasn't ready for prime time.  Since you need a
solution now (or, preferably, sooner), don't wait for it.  The
authors are planning to have an update path from CVS, so you
could consider a changeover later.
> I'm not against sticking with CVS if it'll do the job, but with the
> thought in mind that eventually business critical tasks will be
> performed, I need the right tool for the job that both programmer and
> graphic designer "end-users" can use.
CVS works pretty well for that.  It is certainly reliable enough
for business-critical tasks (provided you stick to client-server
access, and it sounds like that is indeed the plan).
> In addition, if anyone has any stories/suggestions/tips on preferred Mac
> and Windows clients, I'm open to those.
As I said, WinCVS and MacCVS work well and share a common code base,
although the Windows port has moved ahead of the Mac port.  If you
have users who move between Mac and Windows, this is a definite
advantage.  Even if you don't, it still reduces the support burden
a bit.  There are plenty of other Windows clients, but few other
Mac clients.

You might also want to look at Java clients.  Since MacOS 9 is
behind most other platforms in Java support, and is going to stay
that way, make sure to test the Java clients on your Mac.

My list of CVS clients is at:
It isn't necessarily complete, but it hits most of them.

Now building a CVS reference site at

reply via email to

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