[Top][All Lists]
[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