Re: Is there a safe way to do this kind of offline CVS management ?

[Doug Lee]

On Mon, Apr 04, 2005 at 09:44:21AM -0400, Jim.Hyslop wrote:
> In your first message, the part "Tell everyone that they should not modify
> the central tree" really scares (and annoys) me. Generally, the only
> operations where you should tell people not to check things in are
> maintenance operations that affect the repository directly.

Forgive me here please, but I understand neither what scares and
annoys you, nor what you suggest.  I tell people not to check in
because I have the "active" part of the tree off site at that time.  I
could (and probably should) lock it somehow, but I don't want to
disable READ access to it, because others may want to see it.  But
while I'm working directly with the client, it makes little sense for
anyone else off site to check into that tree anyway, so there's never
been a problem there.

> For your "thousand files in a single directory" issue, you could use the -d
> option in the CVS/modules file to specify that the project should be checked
> out into a directory named enu. That would eliminate you having to use the
> -d option each time you check out a project. The modules file might look
> something like:
> 
> wordpad -s dev -d enu path/in/repository

True, but we do sometimes check out elsewhere; for instance, I'm
trying to set up a build system that checks out a fresh copy from
which to build an installer.  For now though, whenever I make a
release, I often do check out outside of settings\enu.

> For your basic procedures, I would suggest something like this:
> 
> - apply a tag to the files you're going to take on-site
> - 'CVS export' those files 
> - On-site, use 'cvs import' to import them to the local repository.
> - modify, check-in, etc. to your heart's content
> - when done, take a copy of the modified local repository files (*,v) back
> to your office
> - write or find a script or tool that will pull out the changes you've done
> on-site, and apply them to the local repository, on a branch created from
> the tag in step (1)
> - merge changes from the branch to the head
> 
> On subsequent visits, you can re-import the latest version of the
> repository, and merge any changes made locally.

A viable alternative indeed.  Again though, since I don't expect local
(not at client site) commits while I'm at the client site, I don't
think I should need a branch for each visit.  I do tag at both ends of
a site visit though.  Your approach does allow off-site modifications
without collision, which I will keep in mind.
 
> -- 
> Jim Hyslop
> Senior Software Designer
> Leitch Technology International Inc. ( http://www.leitch.com )
> Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )

-- 
Doug Lee           address@hidden        http://www.dlee.org
BART Group         address@hidden   http://www.bartsite.com
"Pray devoutly, but hammer stoutly."
--Sir William G. Benham