Menu
▾
▴
squeak-vmdev
|
From: Rob W. <rwi...@at...> - 2002-05-13 13:51:28
|
"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 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. What are the user access controls available to us from SF? > > 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. Rob |
|
From: <gor...@bl...> - 2002-05-13 14:04:46
|
"Andreas Raab" <And...@gm...> wrote: > Göran, > > > Hmmm, somewhere here it feels like I have missed some posting - I > > thought I was waiting for some feedback from you Andreas? :-) > > I am referring to my post beginning with the line "Long mail > > about CVS, branches, tags etc.". > > That's to a large extent because I'm still digesting what you wrote. Ok. :-) Hope it wasn't too whimsical. > Mind you, I'm no expert at CVS so it somewhat escapes me what a good > model for working in it could be (and that's also why I'm trying to take > you up on the your offer to write something up on it ;-) The book I referenced is IMHO a good buy. But sure, if we can come up with a model then I will write the "manual". > 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 Yes. Probably we will not bother with trying to ensure that noone else commits on the trunk, but hey - if you abuse your given "commit rights" then people will get angry, so I don't think anyone will do that. A good simple "policy" document will suffice. > his or her branch. Merging works by a variety of models depending on > who's got what amount of time. Correct?! Yes. > 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. We I don't think it will be that complicated. If we disregard merging then there is no difference whatsoever, the only thing you do is add a "-r tag" when doing the checkout. Then your workingcopy "knows" it's on the branch so all operations from then on is just like as if it was on the trunk. The only thing people on branches need to be aware of is that they should tag here and there and write good commit comments in order to make the mergework easier, but that is "common sense". So... "complicated"? Naah. ;-) One obvious branch would be an unofficial "bugfix" branch on a release (there should also be an official releasebranch as I have been saying over and over by now). Lex, Bob and others are pretty fast on fixing bugs etc on the Unix port and they would typically use such a branch to get their fixes in quick and easy. Since the branch only contains bugfixes (no new features etc) and it is rooted at a release it will be trivial for Ian - when he feels like it - to merge that stuff down into the release, look it over, try it out and when he is satisifed - commit it on the official release branch. Then he would of course also have to merge it into the trunk too, but for bugfixes (that tend to be rather small and local) it will probably be quite easy. > might argue that this is the price a person has to pay in order to get > write permission at SF but if so, we should all agree on it. Please > vote. Since it seems that people want some form of "process" that filters stuff through a couple of official maintainers then I think this model is fine. It may not be as most projects work, but not that different either I think. > Secondly, I don't understand why somebody who wants to branch would need > to ask for permission to do so. After all, the main branch is unaffected > by this change, isn't it?! What am I missing?! You are not missing anything. Technically noone would need to ask for permission and perhaps we can skip that part as long as we make sure (policy document again) that the branches are documented in a branches.txt file on SF (better than the almighty swiki - this way it is easy to see when it changes etc). Yes, the trunk is unaffected. The only thing I want to avoid is everybody creating branches to left and right... But that is probably prevented by saying a few words about it in the policy document. > Thirdly, we may consider making up "new ports" instead of "long-living > branches". After all, some of the work that might be considered a branch > (since it has the same target platform) is rather an independent port. > Such as, for example, PhiHo's Mob VM. It shares a few files but it > appears to me that it is a separate port rather than a branch. Agree. > Cheers, > - Andreas Cheers, Göran |
|
From: Andreas R. <And...@gm...> - 2002-05-13 14:18:56
|
G=F6ran, Thanks for all the info. So I'd say I'm in for this model at least for the time being. We'll have to figure out more while it develops but it seems like a reasonable starting point for me. Cheers, - Andreas > -----Original Message----- > From: gor...@bl... [mailto:gor...@bl...]=20 > Sent: Monday, May 13, 2002 5:06 PM > To: Andreas Raab > Cc: squ...@li... > Subject: RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @=20 > sourceforge >=20 >=20 > "Andreas Raab" <And...@gm...> wrote: > > G=F6ran, > >=20 > > > Hmmm, somewhere here it feels like I have missed some posting - I > > > thought I was waiting for some feedback from you Andreas? :-) > > > I am referring to my post beginning with the line "Long mail=20 > > > about CVS, branches, tags etc.". > >=20 > > That's to a large extent because I'm still digesting what you wrote. >=20 > Ok. :-) Hope it wasn't too whimsical. >=20 > > Mind you, I'm no expert at CVS so it somewhat escapes me what a good > > model for working in it could be (and that's also why I'm=20 > trying to take > > you up on the your offer to write something up on it ;-) >=20 > The book I referenced is IMHO a good buy. But sure, if we can come up > with a model then I will write the "manual". >=20 > > Let's see if I got you right: You are basically proposing=20 > that there's a > > main trunk in the repository which is guarded by the=20 > maintainer of the > > port. Everyone else having commit permissions can happily=20 > hack away on >=20 > Yes. Probably we will not bother with trying to ensure that noone else > commits on the trunk, but hey - if you abuse your given=20 > "commit rights" > then people will get angry, so I don't think anyone will do=20 > that. A good > simple "policy" document will suffice. >=20 > > his or her branch. Merging works by a variety of models depending on > > who's got what amount of time. Correct?! >=20 > Yes. >=20 > > There are a few points about this that I'm a bit unhappy=20 > with. One is > > that it appears to me that working on a branch may be=20 > complicated. We >=20 > I don't think it will be that complicated. If we disregard=20 > merging then > there is no difference whatsoever, the only thing you do is add a "-r > tag" when doing the checkout. Then your workingcopy "knows"=20 > it's on the > branch so all operations from then on is just like as if it was on the > trunk. >=20 > The only thing people on branches need to be aware of is that they > should tag here and there and write good commit comments in order to > make the mergework easier, but that is "common sense". So... > "complicated"? Naah. ;-) >=20 > One obvious branch would be an unofficial "bugfix" branch on a release > (there should also be an official releasebranch as I have been saying > over and over by now). Lex, Bob and others are pretty fast on fixing > bugs etc on the Unix port and they would typically use such a=20 > branch to > get their fixes in quick and easy. Since the branch only contains > bugfixes (no new features etc) and it is rooted at a release=20 > it will be > trivial for Ian - when he feels like it - to merge that stuff=20 > down into > the release, look it over, try it out and when he is=20 > satisifed - commit > it on the official release branch. Then he would of course=20 > also have to > merge it into the trunk too, but for bugfixes (that tend to be rather > small and local) it will probably be quite easy. >=20 > > might argue that this is the price a person has to pay in=20 > order to get > > write permission at SF but if so, we should all agree on it. Please > > vote. >=20 > Since it seems that people want some form of "process" that filters > stuff through a couple of official maintainers then I think this model > is fine. It may not be as most projects work, but not that different > either I think. >=20 > > Secondly, I don't understand why somebody who wants to=20 > branch would need > > to ask for permission to do so. After all, the main branch=20 > is unaffected > > by this change, isn't it?! What am I missing?! >=20 > You are not missing anything. Technically noone would need to ask for > permission and perhaps we can skip that part as long as we make sure > (policy document again) that the branches are documented in a > branches.txt file on SF (better than the almighty swiki -=20 > this way it is > easy to see when it changes etc). >=20 > Yes, the trunk is unaffected. The only thing I want to avoid is > everybody creating branches to left and right... But that is probably > prevented by saying a few words about it in the policy document. >=20 > > Thirdly, we may consider making up "new ports" instead of=20 > "long-living > > branches". After all, some of the work that might be=20 > considered a branch > > (since it has the same target platform) is rather an=20 > independent port. > > Such as, for example, PhiHo's Mob VM. It shares a few files but it > > appears to me that it is a separate port rather than a branch. >=20 > Agree. >=20 > > Cheers, > > - Andreas >=20 > Cheers, G=F6ran >=20 |
|
From: <gor...@bl...> - 2002-05-13 14:54:35
|
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
|
|
From: <gor...@bl...> - 2002-05-13 15:07:56
|
"Andreas Raab" <And...@gm...> wrote: > Rob, > > > Do we know that we can restrict access to the main trunk to the > > maintainers, then issue expanded rights to select individuals to their > > 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. > > > > What are the user access controls available to us from SF? > > None as far as I know. If you have developer status you have commit > rights anywhere (I think they've never anticipated that kind of strict > distinction that we're discussing here - perhaps it might be worthwhile > to send them a note explaining why we think along these lines). Well, I would guess SF just uses CVS more or less off the shelf but anyway, this might help: https://sourceforge.net/projects/cvssupport/ According to some postings on Usenet it includes ACL functionality. regards, Göran |
|
From: <rwi...@at...> - 2002-05-13 15:12:48
|
> Rob, > > > Do we know that we can restrict access to the main trunk to the > > maintainers, then issue expanded rights to select individuals to their > > 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. > > > > What are the user access controls available to us from SF? > > None as far as I know. If you have developer status you have commit > rights anywhere (I think they've never anticipated that kind of strict > distinction that we're discussing here - perhaps it might be worthwhile > to send them a note explaining why we think along these lines). > > BTW, I've been thinking about the issue of (either accidentally or > non-accidentally) making "mistakes" but (in hindsight) I really don't > think this is going to be a problem. For one thing, we _all_ make > mistakes at times (just remember this fundamentally flawed ClassBuilder > CS recently), CVS can deal with many of the problems in a reasonably > straightforward way, and I also don't think the VM developer community > would tolerate any non-agreeable behavior that would put the stability > of Squeak on _any_ platform at risk. The last line of defense is having > project admin status which (as far as I am aware) all of the primary > maintainers have. Andreas, Hurray! That sounds very reasonable and balanced between stability/reliability and openness. We can take advantage of all the volunteers, yet ensure a level of quality and hopefully minimize flux/thrash. I messed up this process this morning, in fact. The problem wasn't that I committed to the main branch, because *nix wasn't compilable with VMMaker32-7.5 and we are still at the pre-integration stage wrt Ian's code. The problem was that I didn't inform Lex and this dist list that I was doing the work. > > It still bothers me that I _could_ make modifications to (say) the unix > tree but it appears that this can't be helped. Perhaps a good line in > the policy document would be to state that you "Never, NEVER do a 'cvs > commit' from the platforms directory but only from your platform branch > (win32, unix, Mac, Acorn, Cross)". I've been using this policy for me > already and so far it turns out to be a good practical rule. Heh. This is what I did this morning for the changes, but I had to re-checkout the toplevel to add osExports.c. Of course, I had done a 'cvs diff squeak', first, to verify that I was only commiting the files I had planned on commiting. Are the aliases I had defined in the CVSROOT/modules file a good idea? It may be better to checkout the explicit subtrees (Cross and unix in my case). Cheers, Rob PS. I am posting through the web for the first time, since I am at work. I may be too busy later, to post immediately. |
|
From: Lex S. <le...@cc...> - 2002-05-14 14:54:20
|
rwi...@at... wrote: > Heh. This is what I did this morning for the changes, > but I had to re-checkout the toplevel to add > osExports.c. Of course, I had done a 'cvs diff squeak', > first, to verify that I was only commiting the files I > had planned on commiting. > If I commit a whole directory, I cd to platforms/unix first. Usually, though, I commit one file at a time, anyway. "Andreas Raab" <And...@gm...> wrote: > 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. We > might argue that this is the price a person has to pay in order to get > write permission at SF but if so, we should all agree on it. Please > vote. I'm not happy with it, either. We are making this more complicated than it deserves. Are we truly going to maintain old versions? And which VM heads *truly* want to manage merging patches in? I bet it's just one. We all do realize, don't we, that it is very easy to revert changes that you don't like? But the tides are moving. We may as well do it that way I suppose, just to have a point of agreement. -Lex |
|
From: <rwi...@at...> - 2002-05-13 15:43:02
|
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? > > 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. > 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? > "cvs --help tag" gives: Is it correct that tagging the trunk and branching are two separate commands? For instance, we have the latest 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 to branch from that tag: cvs tag -b -c -r 3.2g 3.2g-experimental-protected-memory Is this right? to checkout the branch: cvs checkout -r 3.2g-experimental-protected-memory [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? > > regards, Göran > Cheers, Rob |
|
From: <gor...@bl...> - 2002-05-13 15:48:22
|
rwi...@at... wrote:
[SNIP]
> > It still bothers me that I _could_ make modifications
> to (say) the unix
> > tree but it appears that this can't be helped. Perhaps
> a good line in
> > the policy document would be to state that you "Never,
> NEVER do a 'cvs
> > commit' from the platforms directory but only from
> your platform branch
> > (win32, unix, Mac, Acorn, Cross)". I've been using
> this policy for me
> > already and so far it turns out to be a good practical
> rule.
>
> Heh. This is what I did this morning for the changes,
> but I had to re-checkout the toplevel to add
> osExports.c. Of course, I had done a 'cvs diff squeak',
> first, to verify that I was only commiting the files I
> had planned on commiting.
A good rule is to do a "cvs update" first on the same level that you
intend to commit.
The update will tell you what files are modified "M" and that will be
committed.
You can also then see if other people have just committed stuff ("P"/"U"
etc) that you should take into account before committing.
> Are the aliases I had defined in the CVSROOT/modules
> file a good idea? It may be better to checkout the
> explicit subtrees (Cross and unix in my case).
No, they are fine IMO.
regards, Göran
|
|
From: Tim R. <ti...@su...> - 2002-05-13 16:53:59
|
In message <E17...@le...>
gor...@bl... wrote:
> The update will tell you what files are modified "M" and that will be
> committed.
> You can also then see if other people have just committed stuff ("P"/"U"
> etc) that you should take into account before committing.
Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
(when I managed to commit everybody's open files - I cn't imagine what
the logical argument in favour of that working was) and couldn't find an
explanation in any of my cvs doc (I have assorted webpages snarfed
locally that I use).
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Even a two button mouse gives him too many options.
|
|
From: Bert F. <be...@is...> - 2002-05-13 19:06:03
|
On Mon, 13 May 2002, Tim Rowledge wrote:
> In message <E17...@le...>
> gor...@bl... wrote:
>
>
> > The update will tell you what files are modified "M" and that will be
> > committed.
> > You can also then see if other people have just committed stuff ("P"/"U"
> > etc) that you should take into account before committing.
> Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
> (when I managed to commit everybody's open files - I cn't imagine what
> the logical argument in favour of that working was) and couldn't find an
> explanation in any of my cvs doc (I have assorted webpages snarfed
> locally that I use).
Then you just don't use the right doc. It's mentioned in the info files as
well as here, for example:
http://www.cvshome.org/docs/manual/cvs_16.html#SEC154
U The file was brought up to date with respect to the repository.
P Like `U', but the CVS server sends a patch instead of an entire file
M The file is modified in your working directory.X
C A conflict was detected while trying to merge your changes
-- Bert
|
|
From: Tim R. <ti...@su...> - 2002-05-13 20:43:52
|
In message <Pin...@ba...>
Bert Freudenberg <be...@is...> wrote:
> Then you just don't use the right doc. It's mentioned in the info files as
> well as here, for example:
> http://www.cvshome.org/docs/manual/cvs_16.html#SEC154
Hmm, interesting - I had downloaded the single file version from there
some time ago and my copy is identical (in that area, anyway) _except_
for missing the section on 'P'. Guess it got updated.
I've grabbed the latest now anyway.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Stumped by anything child-proof.
|
|
From: <gor...@bl...> - 2002-05-13 16:01:57
|
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 |
|
From: <gor...@bl...> - 2002-05-13 20:04:27
|
Hi guys!
Quoting Bert Freudenberg <be...@is...>:
> On Mon, 13 May 2002, Tim Rowledge wrote:
> > > The update will tell you what files are modified "M"
and that will
> be
> > > committed.
> > > You can also then see if other people have just committed stuff
> ("P"/"U"
> > > etc) that you should take into account before committing.
> > Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
> > (when I managed to commit everybody's open files - I cn't imagine
> what
> > the logical argument in favour of that working was) and couldn't find
> an
> > explanation in any of my cvs doc (I have assorted webpages snarfed
> > locally that I use).
>
> Then you just don't use the right doc. It's mentioned in the info files
> as
> well as here, for example:
> http://www.cvshome.org/docs/manual/cvs_16.html#SEC154
>
> U The file was brought up to date with respect to the repository.
> P Like `U', but the CVS server sends a patch instead of an entire file
> M The file is modified in your working directory.X
> C A conflict was detected while trying to merge your changes
>
> -- Bert
Yes, a "U" is FULLY equivalent to a "P" - it means that your workingcopy was
just updated because someone has committed a new version of the file since you
last updated it. "M" means that the file in question has a local modification in
your working copy and if you commit it a new revision will be created for it.
Interestingly a file marked "M" could very well have been updated during the
update and automerged without conflict. You would have to study the output to
discover that actually - I don't think you can see that otherwise. A bit dumb.
Anyway - if you have made a change, compiled, tested and everything is dandy and
then you do an update right before commit - IF you then get U/Ps then you should
recompile/test again IMHO and perhaps study what came in.
Otherwise you run the risk of committing something that won't build. If the
update comes out clean then go ahead, nothing has changed since you last updated
so everything must be OK.
A nice sideeffect with running the update before commit is that you also see the
Ms and based on that you can more easily decide what to write in the commit
comment. It is quite common that you think you have only fixed bug X and when
you do the update you realize that, hey, I almost forgot - I also edited file Z
to fix that little buglet Y...
regards, Göran
PS. I am actually adding support for "P" in sqcvs - the CVS protocol
is capability based and if the client says "Nope, I can't handle patch
files" then those don't get sent by the server- no "P"s shows up. But that is a
good thing to be able to handle so I just added it actually... :-) The unified
diff is very easy to apply. DS
Göran Hultgren, gor...@bl...
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek
|
|
From: Tim R. <ti...@su...> - 2002-05-13 20:52:19
|
In message <102...@ma...>
G=F6ran Hultgren <gor...@bl...> wrote:
> PS. I am actually adding support for "P" in sqcvs - the CVS protocol
> is capability based and if the client says "Nope, I can't handle patch
> files" then those don't get sent by the server- no "P"s shows up. But t=
hat is a
> good thing to be able to handle so I just added it actually... :-) The =
unified
> diff is very easy to apply.
Things I'd like to see sqCVS handle:-
+ renaming - surely it isn't too hard to do the remove, commit, replace,
commit, handle paths & directories in one clean package? It's so painful
with plain cvs.
+ err, actually, that would cover it, since obviously removing & adding
would have been fixed as a side effect.
tim
--=20
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt
|
|
From: Rob W. <rwi...@at...> - 2002-05-14 04:36:42
|
gor...@bl... wrote: > rwi...@at... wrote: > > our process. Do we want to complicate it further, > > technically, by trying to tackle cvssupport? > > Honestly, no! :-) But we can check it out later. Whew. That's good. :) My opinion is that we are much better off using a trust system and minimizing the technical barriers. We all want to create the highest quality system we can. > > How far off are we to 3.2final? > > No idea. ;-) Me neither, but it feels like we are getting close. What can I do to help cvsproj and sqcvs along? > 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). Note that this has been a hypothetical; I didn't actually tag the unix stuff as I feel that that is Lex's or Ian's perogative. There could be a lot of branches off of the trunk, which could get unweildy with all of the Root-of-XXX. I like John's approach of using a <major>.<minor>.<patch>.0 (i.e. 3.2.7.0), then branches could be <major>.<minor>.<patch>.<branch>...(<subbranch>) (i.e. 3.2.7.1). I suppose we could even tag a particular revision of a branch as the root of a subbranch, like 3.2.7.1.0, and the subbranch would be 3.2.7.1.1 and so on. > 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". I agree, especially given your discussion of verifying with cvs update. > > 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. I see. Now you won't be affecting the trunk at all. > You can > also move an existing checked out trunk onto the branch by using: > cvs update -r 3.2g-experimental-protected-memory hmmm. I don't follow you here. What exactly does this do? Oh. Are you saying that if I have done cvs co -r 3.2g then I could do cvs up -r 3.2g-experimental-protected-memory and my working copy will now be the latest in the branched tipped with 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 Will this take the latest from the trunk, or the root? > 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. Very nice - I am d/ling tkcvs as I write this. thanks and cheers, Rob |
|
From: <gor...@bl...> - 2002-05-14 06:11:55
|
Rob Withers <rwi...@at...> wrote: > gor...@bl... wrote: > > rwi...@at... wrote: > > > our process. Do we want to complicate it further, > > > technically, by trying to tackle cvssupport? > > > > Honestly, no! :-) But we can check it out later. > > Whew. That's good. :) My opinion is that we are much better off > using a trust system and minimizing the technical barriers. We all want > to create the highest quality system we can. I agree - I am just "playing along" since there are a few people worried about these things. But as you say - I also think that a trustsystem is quite enough - if we can't trust each other then we shouldn't give each other commit capability IMHO. :-) > > > How far off are we to 3.2final? > > > > No idea. ;-) > > Me neither, but it feels like we are getting close. What can I do to > help cvsproj and sqcvs along? Well, if you are interested in hacking on sqcvs - which is a CVS pserver-client/server protocol implementation - then I should write down an email for you with the most pressing todo-list. Most of those todos are pretty damn easy to implement so I think it is a "rewarding point in time" to jump in! :-) Sqcvs is meant to be "plugged in" with VMMaker making it even easier to build your own VM. Then of course - a nice Morphic UI on top of Sqcvs wouldn't hurt - then we have our very own supercrossplatform CVS client! :-) One thing to start with would be to integrate it in FileList and friends. That would perhaps be nice. Anyway - if you are still interested then I can whip up an email to get you started. Regarding cvstproj - which is a different thing - you should talk to Martin Kobetic. Currently it looks like Avi Bryant is building something along the same lines as cvstproj (same goal, different approach) so you may want to talk to him too. > > 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). > > Note that this has been a hypothetical; I didn't actually tag the unix > stuff as I feel that that is Lex's or Ian's perogative. I know! I was just "pretending along". :-) > There could be a lot of branches off of the trunk, which could get > unweildy with all of the Root-of-XXX. I like John's approach of using a > <major>.<minor>.<patch>.0 (i.e. 3.2.7.0), then branches could be > <major>.<minor>.<patch>.<branch>...(<subbranch>) (i.e. 3.2.7.1). I > suppose we could even tag a particular revision of a branch as the root > of a subbranch, like 3.2.7.1.0, and the subbranch would be 3.2.7.1.1 and > so on. I still want branchtags to have a special prefix/suffix like "-branch" and the branch root tags to have another special prefix/suffix like "-root" or "Rootof-" or whatever. A CVS repository quickly gets a LOT of tags so you want to have a good naming standard for them and be able to see what tags are branch tags etc. This is advice coming directly from Karl Fogel's CVS book btw. > > 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". > > I agree, especially given your discussion of verifying with cvs update. > > > > 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. > > I see. Now you won't be affecting the trunk at all. Right. > > You can > > also move an existing checked out trunk onto the branch by using: > > cvs update -r 3.2g-experimental-protected-memory > > hmmm. I don't follow you here. What exactly does this do? Oh. Are I am saying that an update operation with a revision option will update your workingcopy to the state of the tag. In my example I had checked out the trunk and wanted suddenly to work on the branch - so I updated my trunk over to the branch by giving update the branch tag as an argument. This will make CVS update/patch only those files that are different in the branch. The end result is the same as if I had done a checkout of the branch. > you saying that if I have done > > cvs co -r 3.2g That would check out the trunk but as it was when tagged with "3.2g" - which is not a branch tag. You are still on the trunk but with a sticky tag "3.2g". The effect is that you can't commit anything because you can not change "history"! But that is a sidepoint. > then I could do > > cvs up -r 3.2g-experimental-protected-memory Sure, this would move the workingcopy over to the tip/head of the branch - since the branch tag always refer to the tip of the branch (only changing the files that needs to be changed). > and my working copy will now be the latest in the branched tipped with > 3.2g-experimental-protected-memory? "branched tipped with 3.2g-experimental-protected-memory?" - I am not following your english here. But I think the answer is Yes - your workingcopy is now the latest in the branch called "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 > > Will this take the latest from the trunk, or the root? Right. All sticky tags are cleared so CVS will then take the latest on the trunk - can also be referred to as HEAD (a pseudo-tag representing the head of the trunk). > > 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. > > Very nice - I am d/ling tkcvs as I write this. > > thanks and cheers, > Rob No problem - keep hammering, hopefully other people not versant in CVS will learn something too! :-) regards, Göran |
|
From: <gor...@bl...> - 2002-05-14 15:29:38
|
"Lex Spoon" <le...@cc...> wrote: [SNIP] > "Andreas Raab" <And...@gm...> wrote: > > 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. We > > might argue that this is the price a person has to pay in order to get > > write permission at SF but if so, we should all agree on it. Please > > vote. > > I'm not happy with it, either. We are making this more complicated than > it deserves. Are we truly going to maintain old versions? And which VM Perhaps not. But if the situation arises then such a releasebranch is good to have. Note that we don't create the release branch UNTIL we really want to commit fixes on it. > heads *truly* want to manage merging patches in? I bet it's just one. Well, at least two I think. Andreas and Ian! :-) But sure - if the maintainers turns out to be a bottleneck then we will just have to fix the working process. The good point here is that Ian and Andreas are "in the game". > We all do realize, don't we, that it is very easy to revert changes that > you don't like? I hope so! :-) You can even with some trickery erase "history" from the RCS files. Well, that is not so easy - but doable. > But the tides are moving. We may as well do it that way I suppose, just > to have a point of agreement. Yes. > -Lex regards, Göran PS. Time is up for my offer. Sorry guys! ;-) Well... Let's put it this way - until all people signed up on SF have in some way vocalized a "yes" for the model described then I won't begin writing the policy document. I just don't want to spend time on something as boring as documentation if it doesn't get used in the end... DS |
|
From: Rob W. <rwi...@at...> - 2002-05-15 05:23:51
|
gor...@bl... wrote: > Well, if you are interested in hacking on sqcvs - which is a CVS > pserver-client/server protocol implementation - then I should write down > an email for you with the most pressing todo-list. Most of those todos > are pretty damn easy to implement so I think it is a "rewarding point in > time" to jump in! :-) > > Sqcvs is meant to be "plugged in" with VMMaker making it even easier to > build your own VM. Then of course - a nice Morphic UI on top of Sqcvs > wouldn't hurt - then we have our very own supercrossplatform CVS client! > :-) > > One thing to start with would be to integrate it in FileList and > friends. That would perhaps be nice. Anyway - if you are still > interested then I can whip up an email to get you started. > > Regarding cvstproj - which is a different thing - you should talk to > Martin Kobetic. Currently it looks like Avi Bryant is building something > along the same lines as cvstproj (same goal, different approach) so you > may want to talk to him too. Hey Goran, I would welcome the email you mention writing, basically a roadmap of integrating cvs support into Squeak. As sqcvs currently stands, we can probably d/l the trunk to the file-system, then generate our code, right? Otherwise we should get that working, first. Following that, you mention other protocol features (commit, etc), then a UI evolving through increasing complexity. I am certainly up for helping you get the VMMakerTool using cvs, but I am not so sure about the rest. It seems we have competing implementations, already. I don't have a whole lot of time, and it has to be spread out, but I can help. > "branched tipped with 3.2g-experimental-protected-memory?" - I am not > following your english here. What english? :) > No problem - keep hammering, hopefully other people not versant in CVS > will learn something too! :-) I think the important point to agree on is when to tag the main trunk with a root. I feel this should be done at major release points, or experimental branches only. I have certainly learned something! Cheers, Rob |
|
From: Rob W. <rwi...@at...> - 2002-05-15 05:23:57
|
"Lex Spoon" <le...@cc...> wrote: > rwi...@at... wrote: > > Heh. This is what I did this morning for the changes, > > but I had to re-checkout the toplevel to add > > osExports.c. Of course, I had done a 'cvs diff squeak', > > first, to verify that I was only commiting the files I > > had planned on commiting. > > > > If I commit a whole directory, I cd to platforms/unix first. Usually, > though, I commit one file at a time, anyway. That works and is safe. Either the cvs diff or the cvs update will both inform you which files are modified, so you can make sure you don't commit anything accidentally. BTW, did my unix commits look ok to you, for VMMaker32-7.5? > > > "Andreas Raab" <And...@gm...> wrote: > > 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. We > > might argue that this is the price a person has to pay in order to get > > write permission at SF but if so, we should all agree on it. Please > > vote. > > I'm not happy with it, either. We are making this more complicated than > it deserves. Are we truly going to maintain old versions? And which VM > heads *truly* want to manage merging patches in? I bet it's just one. > We all do realize, don't we, that it is very easy to revert changes that > you don't like? > > But the tides are moving. We may as well do it that way I suppose, just > to have a point of agreement. I think we just tag the main trunk for the major releases. This way we can get back to that point for testing reported bugs, etc. I pretty much see everyone hacking in the trunk and this will cause ongoing problems of inconsistent platform support for new features. We have been fighting this since day one of using SF with VMMaker, but the response time is typically very short. I don't know how we can resolve this. Cheers, Rob |
|
From: <gor...@bl...> - 2002-05-15 07:23:03
|
Rob Withers <rwi...@at...> wrote: > gor...@bl... wrote: > > Well, if you are interested in hacking on sqcvs - which is a CVS > > pserver-client/server protocol implementation - then I should write down > > an email for you with the most pressing todo-list. Most of those todos > > are pretty damn easy to implement so I think it is a "rewarding point in > > time" to jump in! :-) > > > > Sqcvs is meant to be "plugged in" with VMMaker making it even easier to > > build your own VM. Then of course - a nice Morphic UI on top of Sqcvs > > wouldn't hurt - then we have our very own supercrossplatform CVS client! > > :-) > > > > One thing to start with would be to integrate it in FileList and > > friends. That would perhaps be nice. Anyway - if you are still > > interested then I can whip up an email to get you started. > > > > Regarding cvstproj - which is a different thing - you should talk to > > Martin Kobetic. Currently it looks like Avi Bryant is building something > > along the same lines as cvstproj (same goal, different approach) so you > > may want to talk to him too. > > Hey Goran, > > I would welcome the email you mention writing, basically a roadmap of > integrating cvs support into Squeak. As sqcvs currently stands, we can Sure. > probably d/l the trunk to the file-system, then generate our code, > right? Otherwise we should get that working, first. Following that, That already works. I posted Tim a couple of lines of code that does that and he said it worked fine. :-) The only thing stopping us from having such a "button" in VMMaker is that such a checkout doesn't create compatible CVS clientside "state" files, so you can't use another CVS client on that workingcopy. Oops. =Not very useful. That is one of the things on the todo. > you mention other protocol features (commit, etc), then a UI evolving > through increasing complexity. Commit actually already works. It's basically add/remove that is missing today. Well, some other things of course... > I am certainly up for helping you get the VMMakerTool using cvs, but I Cool. I will write that roadmap. > am not so sure about the rest. It seems we have competing > implementations, already. I don't have a whole lot of time, and it has Eh, the rest? Competing implementations? > to be spread out, but I can help. > > > "branched tipped with 3.2g-experimental-protected-memory?" - I am not > > following your english here. > > What english? :) > > > No problem - keep hammering, hopefully other people not versant in CVS > > will learn something too! :-) > > I think the important point to agree on is when to tag the main trunk > with a root. I feel this should be done at major release points, or > experimental branches only. I have certainly learned something! Yes, the typical tagpoints for the trunk would be: - When a release is made. Those tags should be called "yadayada-release" or similar. - When a branch is made. Those tags mark the root of the branch and shoule be called "yadayada-root" or similar. - When some other interesting point in time is needed to be marked - typically before and after mergework. When you work with branches you often want to tag before merging and when the merging is done. This is mainly to facilitate further mergework in the future. But of course - since we will mostly be merging in one direction from the branches into the trunk such tags are mostly important on the branch. regards, Göran |
|
From: <gor...@bl...> - 2002-05-22 06:16:57
|
Bert Freudenberg <be...@is...> wrote: > With the commitinfo script it is easy to restrict access on a directory > basis. It's somewhat harder to limit access to individual files. But I see > no way to ensure a file is indeed committed to a branch, rather than to > the trunk. See hits on: http://groups.google.com/groups?q=commitinfo+restrict+branch It looks doable. I haven't followed up the leads found though. regards, Göran |
|
From: Rob W. <rwi...@at...> - 2002-05-23 03:29:44
|
Ian Piumarta <ian...@in...> wrote: > On Mon, 13 May 2002, Rob Withers 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 > > branches? > > You can do it with a trivial commitinfo script to filter the usernames > that are allowed to commit to a particular area. (The script is called on > every commit with env vars and arguments telling who, what, where, etc. > If the script exits with nonzero then the commit is aborted. A few lines > of case/sed/test/etc. does the trick.) > > Of course, for this to be in any way secure, SF must only allow admins to > meddle with the contents of CVSROOT/commitinfo. It seems this would work technically. I must ask if you are really, really...really sure you aren't comfortable with just leaving it open and tagging things voraciously, so we can recover the stable points? Adding technical complexity to publishing code sounds scary to me, but then I'm not the one who gets yelled at. :) Are you aware of the commit mailing list for the squeak SF? In this way, you can see all commits that occur and the 'VM harvesters' could verify operation. welcome back, Rob |
|
From: Andreas R. <And...@gm...> - 2002-05-13 14:32:35
|
Rob, > Do we know that we can restrict access to the main trunk to the > maintainers, then issue expanded rights to select individuals to their > 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. > > What are the user access controls available to us from SF? None as far as I know. If you have developer status you have commit rights anywhere (I think they've never anticipated that kind of strict distinction that we're discussing here - perhaps it might be worthwhile to send them a note explaining why we think along these lines). BTW, I've been thinking about the issue of (either accidentally or non-accidentally) making "mistakes" but (in hindsight) I really don't think this is going to be a problem. For one thing, we _all_ make mistakes at times (just remember this fundamentally flawed ClassBuilder CS recently), CVS can deal with many of the problems in a reasonably straightforward way, and I also don't think the VM developer community would tolerate any non-agreeable behavior that would put the stability of Squeak on _any_ platform at risk. The last line of defense is having project admin status which (as far as I am aware) all of the primary maintainers have. It still bothers me that I _could_ make modifications to (say) the unix tree but it appears that this can't be helped. Perhaps a good line in the policy document would be to state that you "Never, NEVER do a 'cvs commit' from the platforms directory but only from your platform branch (win32, unix, Mac, Acorn, Cross)". I've been using this policy for me already and so far it turns out to be a good practical rule. Cheers, - Andreas |
|
From: Andreas R. <And...@gm...> - 2002-05-13 15:12:41
|
Folks, Since it seems that we're really making some progress with the VM stuff at source forge I'd like to raise one additional issue. It's the question who should be a developer (e.g., have commit rights) and how some person could become one. Looking at the list we have 18 developers some of which I don't even know. This will be an ongoing problem and I'd like to make a small proposal here: Since we can't know every last person we have to put our trust in the persons we do know and trust enough to have write access. I'd like to see a "vouching" scheme where any developer in the Squeak project needs a vouch by at least one other developer. This vouch implies a certain indirect responsibility - in other words, if the person who you vouched for misbehaves you are responsible for a) making sure he or she behaves according to the policies and b) cleaning up for this person's mess in case he or she doesn't. You can remove your vouch if you no longer trust this person's ability to handle things properly. A developer without a vouch will be automatically removed from the list. So will any "disconnected" networks of vouches. In even other words, the vouches represent "pointers to developers" and anyone who isn't pointed to will be garbage collected ;-) The roots of that system are the primary developers for each port. For anyone who wants to join the developers he or she needs a vouch by an existing developer. The existing developer is responsible for explaining the policies and rules on VMDev. The existing developer can also ask one of the people having vouched for him to give the new developer write access. Once you're at the roots of that system you will end up with a project admin who will be able to make the necessary modifications. It also means that people who have been vouched for by project admins have a "shorter path" to getting new people in than developers who are only connected through "three indirect links" (of course, if you can get a project admin to vouch for you directly, that's the easiest way). This models the trust level which weakens with any new indirection. It also means that any developer shoud try to get a vouch from the roots, e.g., proove to one the primary maintainers that he or she is a worthwhile addition to the Squeak VMDev community. Here are the people on the developers list I can vouch for: * Bert Freudenberg * Cees de Groot * G=F6ran Hultgren * Ian Piumarta * John McIntosh * Lex Spoon * Michael R=FCger * Tim Rowledge * Rob Withers [Note that I have included the primary developers (roots) to indicate that my trust in their abilities].=20 What do you think? Cheers, - Andreas |
Thanks for helping keep SourceForge clean.
X