info-cvs
[Top][All Lists]
Advanced

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

Re: Automating CVS


From: Tobias Brox
Subject: Re: Automating CVS
Date: Wed, 26 Sep 2001 15:33:32 +0400
User-agent: Mutt/1.0.1i

[raptor - Wed at 11:38:18AM +0300]
> Is there some workaraound that can take care of automating those stuff so
> that :
> 1. All developers has to be able to directly edit the files on
> PrimaryDevServer (currently via FTP)
> 2. All developers has to WORRY mostly of their own dev server when it comes
> to CVS commits/updates/etc, but still PrimaryDevServer has to be up-to-date

I'm not sure I understand you clearly, but maybe I've been in similar
situations.  What we did was to do _all_ code changes in our personal work
directories (on the personal workstations), commit them into the CVS, and
then update them at the PrimaryDevServer.  I did make some simple scripts
that made PrimaryDevServer update automagically every time somebody did a
commit.

Having some automated test cases at the PrimaryDevServer that reports back
about troubles and eventually reverts to the last working version can also
be a good idea. In that case, the developer has to update his sources and
resolve the conflicts at his personal development workstation.  It should be
an easy thing to do.  I'm currently unemployed, btw. :-)

I really don't see any need for editing the sources at the PrimaryDevServer
through FTP, neither to do any cvs commits from it.  All cvs commits should
be done from the personal work directories, I'd daresay that's a cornerstone
of the cvs philosophy.

If people don't want to their local source to break through updates from
other developers, they should make individual branches, and merge their code
changes into the branch used by PrimaryDevServer (typically the HEAD
branch).

> May be I'm searching for some AUTOMATING tool.... which can gratiously
> handle Conflicts.. or in short I want to remove the burden of the Developers
> (but also my burden 'cause I'm also developer :") )

I don't think automated conflict handling is a good idea... it should, in
the very most cases, be done by humans.  Eventually you will need some
context-aware semi-intelligent conflict-handling tool - creating such a tool
is difficult enough ... beeing sure that it always does the Right thing is a
great deal worse.

Conflicts can often be avoided by a bare minimum of cooperation and
communication between the developers.  I don't think that can or should be
automated away.

-- 
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/



reply via email to

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