RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

Rob Withers <rwi...@at...> wrote:
> "Andreas Raab" <And...@gm...> wrote:
> > Let's see if I got you right: You are basically proposing that there's a
> > main trunk in the repository which is guarded by the maintainer of the
> > port. Everyone else having commit permissions can happily hack away on
> > his or her branch. Merging works by a variety of models depending on
> > who's got what amount of time. Correct?!
> 
> Do we know that we can restrict access to the main trunk to the
> maintainers, then issue expanded rights to select individuals to their

CVS has no such facility out-of-the-box AFAIK. But I think a policy will
suffice.
After all, (IMHO) developers should only get commit "rights" when we
"trust" them.

> branches?  The original model we had discussed was that the main trunk
> was the most volitile, and both experimental work and stable releases
> (and it's patches) are managed as branches.  

The only difference as I can see is that we restrict commit rights to
the trunk to the maintainers and at the same time raise the bar for
those commits - they should be "stable" in some sense, at least tested
and validated to work by the maintainers themselves. So a checkout of
HEAD (the tip of the trunk) should get you a pretty descent VM though it
has not gone through any "release testphase".

But as you say: When releases are made then we still should create a
release branch on which we can apply fixes later on (when the trunk has
moved forward). And any experimental work are done in branches.

> What are the user access controls available to us from SF?

I haven't checked.
 
> > There are a few points about this that I'm a bit unhappy with. One is
> > that it appears to me that working on a branch may be complicated. 
> 
> I have forgotten the commands to tag the trunk, then branch (with a
> branch tag).  It really isn't that difficult once we know these
> commands.

"cvs --help tag" gives:

Usage: cvs tag [-bcdFflR] [-r rev|-D date] tag [files...]
        -b      Make the tag a "branch" tag, allowing concurrent
development.
        -c      Check that working files are unmodified.
        -d      Delete the given tag.
        -F      Move tag if it already exists.
        -f      Force a head revision match if tag/date not found.
        -l      Local directory only, not recursive.
        -R      Process directories recursively.
        -r rev  Existing revision/tag.
        -D      Existing date.
(Specify the --help global option for a list of other help options)

So tagging the trunk is done by (since -R is default) cd'ing to the top
directory in your workingcopy containing the revisions (a checked out
trunk) that you want to tag (the tag command tags the revisions that YOU
have in your workingcopy so you don't need to worry if someone else has
just committed something):

cvs tag MYLITTLETAG

Just add a "-b" to create a branch at this point (which technically is
just a special kind of tag). WinCVS/MacCVS has a little dialog for this
of course.

Btw - WinCVS and MacCVS are pretty nice and they are only "wrappers"
around the cvs executable so they are no less safe to use than CLI cvs.
So, if you are on Win32 or Mac - use them. If you are on Unix then there
are a few UIs around - I am playing around myself with LinCVS and tkcvs.
There are also others and I think that all of them except for a Java
implementation I don't know the name of, are wrappers around the cvs
executable. 

Sidenote: This means that there aren't that many OpenSource pserver
protocol implementations out there AFAICT. The CVS original, sqcvs and
the Java implementation are the ones I know of. Oh yes, and one special
for VAJ that we used a while ago.

> Rob

regards, Göran