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

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

rwi...@at... wrote:
> Göran wrote:
> > Rob Withers <rwi...@at...> wrote:
> > > 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.
> 
> Gosh, I really like what I am hearing from Andreas and I 
> saw your other post regarding cvssupport.  It feels like 
> we are about 80% of the way there for controlling cvs in 
> our process.  Do we want to complicate it further, 
> technically, by trying to tackle cvssupport?

Honestly, no! :-) But we can check it out later.

> > > 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".
> 
> Yes, this is what I was thinking.   The unfortunate side-
> effect of a structural change, like the exports change, 
> is that is not all ports are migrated, and you are left 
> with some ports that stop compiling.  This kind of work 
> really should be done on branches, until all ports 
> support the new change, then merge them in.  I think 
> this is achievable once we all know how to branch and 
> merge.

Yes.

> > 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.
> 
> How far off are we to 3.2final?

No idea. ;-)

> > "cvs --help tag" gives:
> 
> Is it correct that tagging the trunk and branching are 
> two separate commands?  For instance, we have the latest 

Yes - the reason for tagging right before doing a branch is that
otherwise you will not have a tag to refer to when you need to refer to
the "root" of the branch. The branch tag itself refers to the tip of the
branch - NOT the root. And you will need this later when you do the
merge work.

> code from the trunk loaded and say we want to tag the 
> main for 3.2g, then I want to branch from there for 3.2g-
> experimental-protected-memory.  
> 
> to tag the main trunk:
> 
> cvs tag -c 3.2g

Yes.

> to branch from that tag:
> 
> cvs tag -b -c -r 3.2g 3.2g-experimental-protected-memory
>
> Is this right?

Yes, but the tag command tags exactly those revisions that you have in
your own working area. A good rule though is to call the branch tags
"XXX-branch" and the branch root tags "Root-of-XXX". Or something like
that. This is stuff I will write about in the policy doc.

Since you tagged those on the line above I assume you still have those
revisions :-) so the "-r 3.2g" is actually unnecessary (but correct).

There is also the command "rtag" that can tag stuff without having a
workingcopy but I never use that - I feel in more control with "tag".

> to checkout the branch:
> 
> cvs checkout -r 3.2g-experimental-protected-memory

Yes, this would check out the tip of the branch. This will place a so
called "sticky tag" on your files in your workingcopy so that all
operations from now on happen on the branch. Quite convenient. You can
also move an existing checked out trunk onto the branch by using:
cvs update -r 3.2g-experimental-protected-memory

This would have the same result as the checkout but with much less IO.
And moving it back to the trunk is done by clearing the sticky tag:

cvs update -A

> [snip cvs tag help]
> 
> > If you are on Unix then there
> > are a few UIs around - I am playing around myself with 
> LinCVS and tkcvs.
> 
> hmmm.  I should go take a look at those.  Which is 
> better?

My impression is that LinCVS is a poor clone of WinCVS/MacCVS (which are
pretty good by now). TkCVS looks interesting and has more advanced
features.

Then there are numerous others like Pharmacy (GNOME) etc. Haven't tried
them yet.

regards, Göran