info-cvs
[Top][All Lists]
Advanced

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

Re: Setting up first repository


From: Roddie
Subject: Re: Setting up first repository
Date: Wed, 09 Mar 2005 09:01:45 +0000
User-agent: Microsoft-Entourage/10.1.0.2006

on 5/3/05 19:23, Pierre Asselin at address@hidden wrote:

> Roddie <address@hidden> wrote:
>> [ ... ]
>> The repository could be on either computer, but I plan to put it on the
>> co-lo.
> 
> You may want to dry-run this on your laptop.  Run cvs init to start a
> repository, use it locally for a while, wipe it out when you have
> enough experience to init a new repository on your co-lo.
> 
> The dry run is just to play with cvs commands for a while.  You have
> a pretty strong incentive to switch to your final repository so you can
> distribute files to the live site through cvs.

This is a good idea and I've been trying it. I can log in OK, but when I try
to import a trial project using "cvs -d
:pserver:address@hidden:/usr/local/CVS import myProj no-vendor release-0"
I get "cvs [import aborted]: reading CVS/Tag: Not a directory".

I may also have Unix permission problems - I had to make CVSROOT chmod 757
(though there may be "lesser" options - Unix permissions are not instinctive
yet!)

I have a passwd file with "roddie:abcxyz:roddie" where "roddie" is a Unix
administrator.

>> [ ... ]
> [...]
> 
>> Occasionally I make changes direct to the live site. These are usually
>> trivial updates of content, but remembering to make them also in the
>> development files is a nuisance. In this instance I would make changes to
>> the live site, commit them, and then update the development sandbox.
> 
> Then your live site should be a sandbox, and it should be on a branch.
> Otherwise, you won't be allowed to commit your trivial tweaks without
> first running an update, and that would force you to deploy changes
> sooner than you would like.

Good point - I hadn't foreseen the need for a branch so early in the
learning curve.

> Having a release branch is pretty standard.  You fix bugs on the branch
> and merge them back to the trunk so you don't have to fix them twice.
> When your trunk is good, you cut a new release branch and update the
> live sandbox to the new branch.  Post again if the process is not
> clear to you.

Thanks to everyone who responded. I really appreciate the help.

Roddie Grant





reply via email to

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