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

[C. R. Oldham]

>   o Extremely cheap & easy archive (aka repository) creation: Archives
>     are something ordinary users can easily create, without many
>     privileges or special services.

Tom (et al.),

You originally said in your bullet:

>   2) I wanted to persuade my manager, who was shopping for 
>      revision control technology, to choose arch.

The first bullet by Miles above is something that will *scare* some
managers away.  Often they won't understand exactly what an archive is.
Managers are looking for two things (I'm both a manager and a coder, so
I get to look at it from both sides):

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?

CVS in "bare bones" mode (no branching, no tagging) gives us about 70%
of what we need--a way to make sure there is a central location for our
version controlled code.  Anyone who commits to that location generates
a changelog that gets emailed to all the developers.  We can browse that
repo with ViewCVS, hit it with various tools (Tortoise, WinCVS) to help
us understand what happened to our codebase over time.  But there is
only one branch for us--that's HEAD.

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.

2. The second thing managers need is something that Arch provides--easy
tagging and branching.  They need to know that programmers *can* do
easily what CVS makes it hard for them to do--create version controlled
copies of the source code for easy testing.  What the website needs to
specify maybe is some use case scenarios for what it would take to
administratively manage the patchsets.  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.

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...

--cro