info-cvs
[Top][All Lists]
Advanced

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

Re: CVS-Directories disappear when uploading per SFTP-Client


From: Pierre Asselin
Subject: Re: CVS-Directories disappear when uploading per SFTP-Client
Date: Wed, 22 Jun 2005 00:21:39 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (NetBSD/2.0 (i386))

Dennis von Ferenczy <address@hidden> wrote:

> Thanks for your advice. But what will be the advantage? If I get you right,
> then I would have to do a commit every time I want to test the changes in my
> scripts,

Yes.

> even if I have changed only a single line of code

Yes.

> - and even if the code is buggy.

Yes.  If you commit a bug, fix it and commit again.
Try not to commit buggy code, but if it happens once in a while
it's not that big a deal.

You will want to tag the project when you believe there are no
bugs, so you have a well-defined baseline to begin serious testing.
You can also create a stabilization branch where you will do the
bug fixes, or you can wait till you are ready to move the code to the
production server.  You *must* tag the state that you move to production
and you *must* fix any post-release bugs on a branch, to isolate
production from continuing work on the trunk.

Having a trunk and one active branch will complicate the
commitinfo script but it's doable.  Can you run two instances
of the testing server ?  Then your loginfo hook can maintain
two sandboxes, one on the trunk and one on the active release
branch.  You can use a floating tag name for the active branch
to avoid rewriting the loginfo script all the time.  There are
ways;  it's just normal hacking.


> Right now I work locally, have the files mirrored using SSH
> (I'm not sure if cvs can use SSH) can immediately try my changes and if
> everything works as desired I do a commit.

So you upload instead of cvs-commit, and something goes wrong right
at that step and the remote sandbox loses its CVS subdirectories.
Which is worse ?


> Like this I can always be sure,
> that code in the repository is actually code that is working correctly.

No, the code can still be buggy, just not obviously so.  You will
commit buggy code every once in a while even if you can test
before committing.  Like I said, it's not that big a deal.

The best solution would be to fix your IDE's habit of clobbering
the remote CVS directories.  Failing that, my proposal is quite
workable once you get used to it.


-- 
pa at panix dot com


reply via email to

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