gnu-arch-users
[Top][All Lists]
Advanced

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

RE: [Gnu-arch-users] Re: may I pick your brains?


From: Aaron Bentley
Subject: RE: [Gnu-arch-users] Re: may I pick your brains?
Date: 23 Feb 2004 11:43:46 -0500

On Mon, 2004-02-23 at 10:25, C. R. Oldham wrote:

> 1. How can I insure that the hard work of my programmers is stored
> somewhere that we can retrieve it when the programmer leaves, is fired,
> or is hit by a bus?
> 

> Now, being told that my programmers can easily branch and create offline
> copies of archives, littering their file storage area with lots of
> little archives kind of scares me.  To me, that means some pretty strict
> policies and procedures that cannot be enforced via technical means need
> to be put in place.
> 
> This is one of the areas that is making it hard for me to understand how
> to apply Arch to our situation.

Options:
1. Tell programmers "no offline archives".  All programmers commit to
the same archive on a central server

2. Tell programmers "no offline archives".  Each programmer has their
own archive on a central server

3. "offline archives must be mirrored".  You can mirror the
"disconnectable" archives frequently on a central server.  Either the
developer machines push-mirror, or the central server pull-mirrors.

> 
> Please correct me if I'm wrong,
> but using Arch seems to imply that I will need to assign someone the
> task of release-master.  That person will have to accept merge requests,
> apply them to our production code base, and test them.  Right now our
> version control process is a lot more "flat", but we don't tag/branch.
> If it gets committed, then the policy is that the committer tested it on
> a development server.

How you want to handle the release branch is your choice.  If you wish,
you can mimic the current situation by giving all programmers commit
access to the release branch.


> 
> So I'm very much at a loss as to how to manage the patch flow.
> 
> Complicating the issue (and this is getting off-topic, sorry) is that
> our codebase also depends on the status of an Oracle schema.  Certain
> patches should not be applied until certain updates to the schema have
> been made.  That complicates things a lot...

I'm not up on oracle.  The ideal would be to make these schemas
revision-controlled so that any patch that requires a schema change
includes that schema change.

Aaron
-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.





reply via email to

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