Thread: [Sablevm-developer] suggestion: sablevm developer doc
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: David <db...@cs...> - 2003-03-17 19:07:18
|
Hi, Concerning the sablevm documentation for developpers, here what I suggest= : Create a new module for the documentation. Have a 'draft' and a 'main' directory in that module. 'draft' directory checkin policy: anyone can checkin their draft document= ation, no need to wait for Etienne approval. Developpers could have thei= r own subdirs. draft/chris draft/david etc. 'main': This is the complete or almost complete doc that has been reviewed. We have control of what gets put there e.g. only Etienne checkin stuff there. Comments are welcome. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Grzegorz B. P. <ga...@de...> - 2003-03-17 20:24:36
|
W li=B6cie z pon, 17-03-2003, godz. 20:07, David B=E9langer pisze:=20 > Hi, >=20 > Concerning the sablevm documentation for developpers, here what I suggest= : >=20 > Create a new module for the documentation. > Have a 'draft' and a 'main' directory in that module. >=20 > 'draft' directory checkin policy: anyone can checkin their draft > documentation, no need to wait for Etienne approval. Developpers > could have their own subdirs. > draft/chris > draft/david > etc. >=20 > 'main': This is the complete or almost complete doc that has been > reviewed. We have control of what gets put there e.g. only Etienne > checkin stuff there. Hmm... I think I've been reading all recent emails and I haven't seen such big documentation flood :-) I don't know how much documentation we should expect to appear, but I doubt it'd be THAT much of it and so soon that would mandate separete module (and separate tarball). I think I'd rather create 'doc' directory in sablevm module where all approved docs should appear (even Etienne's PhD thesis if for ex. he would like them to be distributed in debian packages). As for the developers' directories. I've seen (for ex. in FireBird) that developers usually have their own subdirs where they keep their own stuff which, for some reason, is not included into the mainline [0]. Again - I think I'd put these dirs in sablevm module for the reason similar to why I wouldn't create new module for docs. KISS - we should not overengineer things. Just my 0.03CAD :-) (about 0.08PLN currently) Grzegorz B. Prokopski [0] Firebird developers have their "home"/"own" dirs in 'firebird' directory in 'firebird' module but I wouldn't go along this pattern. Maybe dir like 'developers' for developers' own dirs would suffice? --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-17 21:04:41
|
I agree also that the doc module/directory/whatever (CVS lets you=20 specify any directory as a "module") should be a subdirectory in the=20 already existing sablevm module. Like sablevm/doc. And I still think a = development branch would make the patching process easier. Also, this=20 way, the main trunk is less likely to ever be broken. Grzegorz B. Prokopski wrote: >W li=B6cie z pon, 17-03-2003, godz. 20:07, David B=E9langer pisze:=20 > =20 > >>Hi, >> >>Concerning the sablevm documentation for developpers, here what I sugge= st: >> >>Create a new module for the documentation. >>Have a 'draft' and a 'main' directory in that module. >> >>'draft' directory checkin policy: anyone can checkin their draft >>documentation, no need to wait for Etienne approval. Developpers >>could have their own subdirs. >>draft/chris >>draft/david >>etc. >> >>'main': This is the complete or almost complete doc that has been >>reviewed. We have control of what gets put there e.g. only Etienne >>checkin stuff there. >> =20 >> >Hmm... I think I've been reading all recent emails and I haven't seen >such big documentation flood :-) > >I don't know how much documentation we should expect to appear, but >I doubt it'd be THAT much of it and so soon that would mandate >separete module (and separate tarball). > >I think I'd rather create 'doc' directory in sablevm module where all >approved docs should appear (even Etienne's PhD thesis if for ex. he >would like them to be distributed in debian packages). > >As for the developers' directories. I've seen (for ex. in FireBird) >that developers usually have their own subdirs where they keep their >own stuff which, for some reason, is not included into the mainline [0].= >Again - I think I'd put these dirs in sablevm module for the reason >similar to why I wouldn't create new module for docs. > >KISS - we should not overengineer things. > >Just my 0.03CAD :-) (about 0.08PLN currently) > > Grzegorz B. Prokopski > >[0] Firebird developers have their "home"/"own" dirs in 'firebird' >directory in 'firebird' module but I wouldn't go along this pattern. >Maybe dir like 'developers' for developers' own dirs would suffice? > > =20 > |
|
From: David <db...@cs...> - 2003-03-17 21:33:43
|
On Mon, Mar 17, 2003 at 09:23:31PM +0100, Grzegorz B. Prokopski wrote: > W li?cie z pon, 17-03-2003, godz. 20:07, David B=E9langer pisze:=20 > > Hi, > >=20 > > Concerning the sablevm documentation for developpers, here what I sug= gest: > >=20 > > Create a new module for the documentation. > > Have a 'draft' and a 'main' directory in that module. > >=20 > > 'draft' directory checkin policy: anyone can checkin their draft > > documentation, no need to wait for Etienne approval. Developpers > > could have their own subdirs. > > draft/chris > > draft/david > > etc. > >=20 > > 'main': This is the complete or almost complete doc that has been > > reviewed. We have control of what gets put there e.g. only Etienne > > checkin stuff there. > Hmm... I think I've been reading all recent emails and I haven't seen > such big documentation flood :-) >=20 > I don't know how much documentation we should expect to appear, but > I doubt it'd be THAT much of it and so soon that would mandate > separete module (and separate tarball). >=20 > I think I'd rather create 'doc' directory in sablevm module where all > approved docs should appear (even Etienne's PhD thesis if for ex. he > would like them to be distributed in debian packages). >=20 > As for the developers' directories. I've seen (for ex. in FireBird) > that developers usually have their own subdirs where they keep their > own stuff which, for some reason, is not included into the mainline [0]= . > Again - I think I'd put these dirs in sablevm module for the reason > similar to why I wouldn't create new module for docs. Actually, after reading your email I think developer directories would be more approriate. I was thinking too much about the doc I am writing right now. The reason I wrote the email in the first place is that I am currently documenting the java stack layout. I am completing it as I need the info. Rather than sending it (then later several updates) to the mailing list, it could be good if I could just put it somewhere. As it is right now, it could be quite useful for people who need that info even if it is still incomplete. David >=20 > KISS - we should not overengineer things. >=20 > Just my 0.03CAD :-) (about 0.08PLN currently) >=20 > Grzegorz B. Prokopski >=20 > [0] Firebird developers have their "home"/"own" dirs in 'firebird' > directory in 'firebird' module but I wouldn't go along this pattern. > Maybe dir like 'developers' for developers' own dirs would suffice? >=20 > --=20 > Grzegorz B. Prokopski <ga...@de...> > Debian http://www.debian.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2003-03-17 20:53:35
|
Hi, How about . . . we just have a development branch and the main trunk.=20 Anyone can hack away on the development branch (obviously trying not to=20 break things), and then once in a while Etienne merges changes into the=20 main trunk. Or some other such multi-developer version control idiom. This would include a doc module that we can all work on. Previously, I had experience setting up a doxygen automatically generated manual for a large, totally undocumented project, and it was not too difficult and actually quite successful (it gives you an html code browser for example). To generate the documentation, one simply=20 typed "make doc". I could do the same thing for SableVM, and then the=20 JavaDoc comments in files would automatically get included. Again, as I wrote before, documentation of actual source files needs to be in the sources themselves. Documentation of the bigger picture obviously can go in a separate file. Latex is fine for this I think (there's docbook, but everyone knows and loves latex already). Both=20 kinds of documentation could go in the doc directory. Cheers, Chris P.S. www.doxygen.org David B=E9langer wrote: >Hi, > >Concerning the sablevm documentation for developpers, here what I sugges= t: > >Create a new module for the documentation. >Have a 'draft' and a 'main' directory in that module. > >'draft' directory checkin policy: anyone can checkin their draft documen= tation, no need to wait for Etienne approval. Developpers could have the= ir own subdirs. >draft/chris >draft/david >etc. > >'main': This is the complete or almost complete doc that has been >reviewed. We have control of what gets put there e.g. only Etienne >checkin stuff there. > > >Comments are welcome. > > >David > >--- > >David B=E9langer >Graduate Student >School of Computer Science >McGill University >Office: MC226 > >Web page: http://www.cs.mcgill.ca/~dbelan2/ >Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt > > > >------------------------------------------------------- >This SF.net email is sponsored by:Crypto Challenge is now open!=20 >Get cracking and register here for some mind boggling fun and=20 >the chance of winning an Apple iPod: >http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > =20 > |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 00:24:34
|
On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: > How about . . . we just have a development branch and the main trunk. > Anyone can hack away on the development branch (obviously trying not to > break things), and then once in a while Etienne merges changes into the > main trunk. Or some other such multi-developer version control idiom. The problem, with CVS, is that when you add something new on a branch, it is considered as head and thus shows up in the main trunk and in the Changelog. Branches *are* badly broken in CVS. This is why I usually use PRCS, but unfortunately it doesn't support remote opertions and isn't supported by SourceForge. Has anyone investigated the newer Subversion free project replacement for CVS? Does it support branches as well as PRCS? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2003-03-18 11:56:42
|
W liście z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: > On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: > > How about . . . we just have a development branch and the main trunk. > > Anyone can hack away on the development branch (obviously trying not to > > break things), and then once in a while Etienne merges changes into the > > main trunk. Or some other such multi-developer version control idiom. > The problem, with CVS, is that when you add something new on a branch, > it is considered as head and thus shows up in the main trunk and in > the Changelog. Are you sure? CVS docs say sth. rather opposite, see http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 "CVS allows you to isolate changes onto a separate line of development, known as a branch. When you change files on a branch, those changes do not appear on the main trunk or other branches." Projects like Mozilla use CVS in the model of HEAD (unstable, development version) and branches (stable releases). If CVS weren't suitable for this - would they use it? I looked at the Subversion status and bugs targetted for next releases. I haven't notoiced any bugs related to branches so there's a chance they're usable w/ SVN. Cheers, GBP -- Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-18 12:23:20
|
Grzegorz B. Prokopski wrote: >W li=B6cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze= :=20 > =20 > >>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: >> =20 >> >>>How about . . . we just have a development branch and the main trunk. = >>>Anyone can hack away on the development branch (obviously trying not t= o=20 >>>break things), and then once in a while Etienne merges changes into th= e=20 >>>main trunk. Or some other such multi-developer version control idiom.= >>> =20 >>> >>The problem, with CVS, is that when you add something new on a branch, >>it is considered as head and thus shows up in the main trunk and in >>the Changelog. >> =20 >> >Are you sure? CVS docs say sth. rather opposite, see >http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 > >"CVS allows you to isolate changes onto a separate line of development, > known as a branch. When you change files on a branch, those changes do > not appear on the main trunk or other branches." > >Projects like Mozilla use CVS in the model of HEAD (unstable, >development version) and branches (stable releases). If CVS weren't >suitable for this - would they use it? > =20 > I kind of like the Mozilla model of development. I think it makes more=20 sense than having a development branch, actually. It says, "If you want = a stable release, don't check out from CVS but rather get a tarball. =20 And if you really want to check out the sources in the tarball from the=20 release branch, you can." CVS may have problems but then again 99% of projects use it so it can't=20 be that severely broken. Chris |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 13:13:45
|
OK guys, you want a proof that CVS is broken. I'll eventually prepare an example for you, but not now; I don't have the time. The example goes along the lines of: You make 2 branches, you "cvs add ; cvs commit" distinct files with the same name on the respective branches, then CVS loses one of the two files without warning. Also, I encourage you to experiment maintaining a branch and trying to merge trunk updates into the branch. CVS is good at the reverse (e.g. merging branch modifs into the trunk), but it not very helpful at tracking trunk changes in a branch. FYI, you might want to learn about how robust merging works. PRCS identified 14 distinct situations: http://prcs.sourceforge.net/merge.html The interesting thing is that PRCS actually asks you before performing an action. Additional reading identifying some of CVS's problems & advantages: http://prcs.sourceforge.net/cvs-vs-prcs.html http://prcs.sourceforge.net/kingdon.html Almost all projects only use a single branch in CVS, so they don't suffer from the problems above. So, your argument does not hold. Do a serious search on the Internet to find about CVS's problems, you you'll see it has many more problems than you think. I di my own homework and tested CVS extensively before drawing my conclusions. Have you done yours? Etienne On Tue, Mar 18, 2003 at 07:23:38AM -0500, Chris Pickett wrote: > Grzegorz B. Prokopski wrote: > > >W li?cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: > > > > > >>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: > >> > >> > >>>How about . . . we just have a development branch and the main trunk. > >>>Anyone can hack away on the development branch (obviously trying not to > >>>break things), and then once in a while Etienne merges changes into the > >>>main trunk. Or some other such multi-developer version control idiom. > >>> > >>> > >>The problem, with CVS, is that when you add something new on a branch, > >>it is considered as head and thus shows up in the main trunk and in > >>the Changelog. > >> > >> > >Are you sure? CVS docs say sth. rather opposite, see > >http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 > > > >"CVS allows you to isolate changes onto a separate line of development, > >known as a branch. When you change files on a branch, those changes do > >not appear on the main trunk or other branches." > > > >Projects like Mozilla use CVS in the model of HEAD (unstable, > >development version) and branches (stable releases). If CVS weren't > >suitable for this - would they use it? > > > > > > I kind of like the Mozilla model of development. I think it makes more > sense than having a development branch, actually. It says, "If you want > a stable release, don't check out from CVS but rather get a tarball. > And if you really want to check out the sources in the tarball from the > release branch, you can." > > CVS may have problems but then again 99% of projects use it so it can't > be that severely broken. > > Chris -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-18 14:27:48
|
Prof. Etienne M. Gagnon wrote: >OK guys, you want a proof that CVS is broken. > >I'll eventually prepare an example for you, but not now; I don't have >the time. The example goes along the lines of: You make 2 branches, >you "cvs add ; cvs commit" distinct files with the same name on the >respective branches, then CVS loses one of the two files without >warning. > >Also, I encourage you to experiment maintaining a branch and trying to >merge trunk updates into the branch. CVS is good at the reverse >(e.g. merging branch modifs into the trunk), but it not very helpful >at tracking trunk changes in a branch. > > No ... the way Mozilla works is every once in a while, it takes a snapshot of development on the trunk and creates a branch. There is a new branch for every release. There is no maintenance of the branch ... you simply take your trunk snapshot and keep working on the branch until it is fixed. Then, when the release occurs, you merge the branch changes into the trunk (which CVS is good at, as you said). The whole point is that once the branch is made, trunk changes don't affect the branch anymore -- and they shouldn't either ... it will have to wait until the next release. http://www.mozilla.org/roadmap.html >FYI, you might want to learn about how robust merging works. PRCS >identified 14 distinct situations: > >http://prcs.sourceforge.net/merge.html > >The interesting thing is that PRCS actually asks you before performing >an action. > >Additional reading identifying some of CVS's problems & advantages: >http://prcs.sourceforge.net/cvs-vs-prcs.html >http://prcs.sourceforge.net/kingdon.html > > I've read all the PRCS stuff before, but it has problems of its own too (ask Ondrej). I don't know what SubVersion is like, I would be open to trying it. But I don't know if SF supports it. Chris >On Tue, Mar 18, 2003 at 07:23:38AM -0500, Chris Pickett wrote: > > >>Grzegorz B. Prokopski wrote: >> >> >> >>>W li?cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: >>> >>> >>> >>> >>>>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: >>>> >>>> >>>> >>>> >>>>>How about . . . we just have a development branch and the main trunk. >>>>>Anyone can hack away on the development branch (obviously trying not to >>>>>break things), and then once in a while Etienne merges changes into the >>>>>main trunk. Or some other such multi-developer version control idiom. >>>>> >>>>> >>>>> >>>>> >>>>The problem, with CVS, is that when you add something new on a branch, >>>>it is considered as head and thus shows up in the main trunk and in >>>>the Changelog. >>>> >>>> >>>> >>>> >>>Are you sure? CVS docs say sth. rather opposite, see >>>http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 >>> >>>"CVS allows you to isolate changes onto a separate line of development, >>>known as a branch. When you change files on a branch, those changes do >>>not appear on the main trunk or other branches." >>> >>>Projects like Mozilla use CVS in the model of HEAD (unstable, >>>development version) and branches (stable releases). If CVS weren't >>>suitable for this - would they use it? >>> >>> >>> >>> >>I kind of like the Mozilla model of development. I think it makes more >>sense than having a development branch, actually. It says, "If you want >>a stable release, don't check out from CVS but rather get a tarball. >>And if you really want to check out the sources in the tarball from the >>release branch, you can." >> >>CVS may have problems but then again 99% of projects use it so it can't >>be that severely broken. >> >>Chris >> >> > > > |
|
From: Chris P. <chr...@ma...> - 2003-03-18 15:00:04
|
There's also extensive user-based support out there for CVS, and people can help you with most of the problems you encounter. http://mail.gnu.org/archive/html/info-cvs/2003-03/index.html As far as I am aware, the primary problems with CVS are directory deletions, renaming, and atomic commits. That and it restricts you to certain branching models if you don't want a big headache. There are, however, many useful scripts people have written to make working with CVS easier. Besides, it seems that we don't really have a choice but to work with CVS, and we want some kind of branch / trunk scheme, so rather than debate the relative merits of CVS / PRCS / Subversion, we should just work with what we have. Chris Chris Pickett wrote: > Prof. Etienne M. Gagnon wrote: > >>OK guys, you want a proof that CVS is broken. >> >>I'll eventually prepare an example for you, but not now; I don't have >>the time. The example goes along the lines of: You make 2 branches, >>you "cvs add ; cvs commit" distinct files with the same name on the >>respective branches, then CVS loses one of the two files without >>warning. >> >>Also, I encourage you to experiment maintaining a branch and trying to >>merge trunk updates into the branch. CVS is good at the reverse >>(e.g. merging branch modifs into the trunk), but it not very helpful >>at tracking trunk changes in a branch. >> >> > No ... the way Mozilla works is every once in a while, it takes a > snapshot of development on the trunk and creates a branch. There is a > new branch for every release. There is no maintenance of the branch > ... you simply take your trunk snapshot and keep working on the branch > until it is fixed. Then, when the release occurs, you merge the > branch changes into the trunk (which CVS is good at, as you said). > The whole point is that once the branch is made, trunk changes don't > affect the branch anymore -- and they shouldn't either ... it will > have to wait until the next release. > > http://www.mozilla.org/roadmap.html > >>FYI, you might want to learn about how robust merging works. PRCS >>identified 14 distinct situations: >> >>http://prcs.sourceforge.net/merge.html >> >>The interesting thing is that PRCS actually asks you before performing >>an action. >> >>Additional reading identifying some of CVS's problems & advantages: >>http://prcs.sourceforge.net/cvs-vs-prcs.html >>http://prcs.sourceforge.net/kingdon.html >> >> > I've read all the PRCS stuff before, but it has problems of its own > too (ask Ondrej). I don't know what SubVersion is like, I would be > open to trying it. But I don't know if SF supports it. > > Chris > >>On Tue, Mar 18, 2003 at 07:23:38AM -0500, Chris Pickett wrote: >> >> >>>Grzegorz B. Prokopski wrote: >>> >>> >>> >>>>W li?cie z wto, 18-03-2003, godz. 01:17, Prof. Etienne M. Gagnon pisze: >>>> >>>> >>>> >>>> >>>>>On Mon, Mar 17, 2003 at 03:53:20PM -0500, Chris Pickett wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>How about . . . we just have a development branch and the main trunk. >>>>>>Anyone can hack away on the development branch (obviously trying not to >>>>>>break things), and then once in a while Etienne merges changes into the >>>>>>main trunk. Or some other such multi-developer version control idiom. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>The problem, with CVS, is that when you add something new on a branch, >>>>>it is considered as head and thus shows up in the main trunk and in >>>>>the Changelog. >>>>> >>>>> >>>>> >>>>> >>>>Are you sure? CVS docs say sth. rather opposite, see >>>>http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49 >>>> >>>>"CVS allows you to isolate changes onto a separate line of development, >>>>known as a branch. When you change files on a branch, those changes do >>>>not appear on the main trunk or other branches." >>>> >>>>Projects like Mozilla use CVS in the model of HEAD (unstable, >>>>development version) and branches (stable releases). If CVS weren't >>>>suitable for this - would they use it? >>>> >>>> >>>> >>>> >>>I kind of like the Mozilla model of development. I think it makes more >>>sense than having a development branch, actually. It says, "If you want >>>a stable release, don't check out from CVS but rather get a tarball. >>>And if you really want to check out the sources in the tarball from the >>>release branch, you can." >>> >>>CVS may have problems but then again 99% of projects use it so it can't >>>be that severely broken. >>> >>>Chris >>> >>> >> >> >> |
|
From: Etienne M. G. <eg...@j-...> - 2003-03-18 15:27:31
|
On Tue, Mar 18, 2003 at 10:00:23AM -0500, Chris Pickett wrote: > There are, however, many useful scripts people have written to make > working with CVS easier. Besides, it seems that we don't really have a > choice but to work with CVS, and we want some kind of branch / trunk > scheme, so rather than debate the relative merits of CVS / PRCS / > Subversion, we should just work with what we have. So, I'll simply add a /doc directory and you can put all your docs there. By default, it won't be included in .tar.gz distributions. If we think some of these should be included, eventually, we simply need to update the auto* files appropriately. No CVS branch headaches, just ChangeLog pollution (which can be painfully avoided by passing the appropriate arguments to cvs2cl). Is that fine with you? Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2003-03-18 17:59:33
|
On Tue, Mar 18, 2003 at 10:26:25AM -0500, Etienne M. Gagnon wrote: > On Tue, Mar 18, 2003 at 10:00:23AM -0500, Chris Pickett wrote: > > There are, however, many useful scripts people have written to make=20 > > working with CVS easier. Besides, it seems that we don't really have= a=20 > > choice but to work with CVS, and we want some kind of branch / trunk=20 > > scheme, so rather than debate the relative merits of CVS / PRCS /=20 > > Subversion, we should just work with what we have. >=20 >=20 > So, I'll simply add a /doc directory and you can put all your docs > there. By default, it won't be included in .tar.gz distributions. If > we think some of these should be included, eventually, we simply need > to update the auto* files appropriately. No CVS branch headaches, > just ChangeLog pollution (which can be painfully avoided by passing > the appropriate arguments to cvs2cl). >=20 > Is that fine with you? It is fine with me. I wasn't expecting my suggestion to turn into a deba= te about which version management system is best, I just wanted some space to put my document draft... :( David >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon eg...@j-... > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink?=20 > You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20 > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 18:32:50
|
Hi David, > It is fine with me. I wasn't expecting my suggestion to turn into a debate > about which version management system is best, I just wanted some space > to put my document draft... :( Not your fault. I guess every project has to debate some technical details from time to time. I hope we're done for a little while. ;-) Just in case you did not know, you automatically gain CVS write access when you are added as a developer of the project (on the SF project page). To set your local snapshot for write access, you have to read the SF documentation and the instructions in: (Developer CVS Access via SSH) http://sourceforge.net/cvs/?group_id=5523 (Other CVS/SSH related docs). E. Information for Members (Developers) of SourceForge.net Projects F. Version Control with CVS (Concurrent Versions System) http://sourceforge.net/docman/?group_id=1 The /doc directory has already been added, so you simply need to "cvs add doc/yourdoc ; cvs commit" when you are ready. IMPORTANT: Always provide a meaningful commit message. Thanks. Have fun! Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 15:14:27
|
On Tue, Mar 18, 2003 at 09:28:08AM -0500, Chris Pickett wrote: >... There is no maintenance of the branch ... That's the problem. CVS's technical weaknesses dictate that branches should be short lived. Except for vendor branches, you can't really think of maintaining *parallel* stable, experimental, and "private" developer branches, where changes are merged from any of these to any other. You can imagine fixing a bug in stable and wanting to merge the fix in experimental, *and* the reverse. CVS is simply not appropriate for such development model. I know, you are suggesting to use some other's project development model (Mozilla). My reply is to say, we should in the short term stick to the simplest model (single trunk) to avoid being bitten by the shortcomings of our support tool (CVS). I have got money from NSERC to buy a server to host our development. Once we have this server, we can install on it whatever tool we think is more appropriate. My quick reading of the subversion home page convinced me that it would be a far more appropriate tool than CVS, allowing us to use the Mozilla Development model or change it easily if we find it is not an appropriate model, without being locked out of interesting models because of the underlying tool. I do not plan to buy the server before the Summer, as I do not have time to shop for it and install it before then. It also gives us the time to determine our needs. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-18 16:26:59
|
Prof. Etienne M. Gagnon wrote: >On Tue, Mar 18, 2003 at 09:28:08AM -0500, Chris Pickett wrote: > > >>... There is no maintenance of the branch ... >> >> > >That's the problem. CVS's technical weaknesses dictate that branches >should be short lived. Except for vendor branches, you can't really >think of maintaining *parallel* stable, experimental, and "private" >developer branches, where changes are merged from any of these to any >other. You can imagine fixing a bug in stable and wanting to merge >the fix in experimental, *and* the reverse. CVS is simply not >appropriate for such development model. > > I agree, CVS only allows for a few different models. However, other than the problem of creating a branch every time you want to release, I can't really see what's wrong with having short-lived branches. >I know, you are suggesting to use some other's project development >model (Mozilla). My reply is to say, we should in the short term >stick to the simplest model (single trunk) to avoid being bitten by >the shortcomings of our support tool (CVS). > Can we have write access in the meantime then? There's only 5 of us right now. It should be fairly easy to track responsibility for a broken trunk, and besides, it's under version control anyway. Primarily this makes it easier to keep up to date with the current repository. Right now David and I have separate CVS's in our accounts, and are continuously updating from the SF CVS using import and then merging. Certainly CVS was not intended to be used this way when there are only a handful of developers. We could set up a cvs-commit mailer that automatically sends out all changes and who made them. Also, although some documentation could go in sablevm/doc, when I'm reading a file, it's nice to put comments in so that I don't have to reread the source later. These comments can become immediately useful to other developers if I have write access, and it saves us both the headache of using patches (me making them, you applying them). I'd also like to set up and auto-generated doxygen documentation system, but this can wait until the summer. The only reason I was suggesting the Mozilla model was because it seems fairly straightforward and because it seems like the best CVS can offer (that and also Mozilla is one of the largest projects using CVS). But a single trunk is okay with me. > I have got money from >NSERC to buy a server to host our development. Once we have this >server, we can install on it whatever tool we think is more >appropriate. My quick reading of the subversion home page convinced >me that it would be a far more appropriate tool than CVS, allowing us >to use the Mozilla Development model or change it easily if we find it >is not an appropriate model, without being locked out of interesting >models because of the underlying tool. > >I do not plan to buy the server before the Summer, as I do not have >time to shop for it and install it before then. It also gives us the >time to determine our needs. > > Okay, I think switching to Subversion is a good idea and I'm happy you're getting that server. It is intended to replace CVS altogether. Hopefully one day, SourceForge will host Subversion-based projects... it just needs a certain critical mass before things pick up. I don't *desperately* need write access, but it would make life a little easier. What do other people working on the source think? David? Grzegorz? Archie? Cheers, Chris |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 17:15:41
|
On Tue, Mar 18, 2003 at 11:27:19AM -0500, Chris Pickett wrote: > I agree, CVS only allows for a few different models. However, other > than the problem of creating a branch every time you want to release, I > can't really see what's wrong with having short-lived branches. How much development experience do you have on moderately big software projects? [I seriously want a detailed answer to this question. You may answer privately, if you think it is more appropriate.] Personally, I do see all kind of problems with short-lived branches (specially for managing an automatically generated changelog file, which is necessary to honor the requirements of the LGPL license, in case you were not aware). I don't have time to justify every single little decision of mine. You will have to learn to live with some of my decisions, or you may fork your own project. One of these decisions is that will live with a single trunk, no branches. The only thing I can do, if you want to put all sort of stuff into CVS, is to start a "distinct module", sablevm-experimental, that could live in parallel, where there would be, again, a single trunk, but where all developers can check-in stuff freely (as long as the code is licensed appropriately, no non-clean-room contribution as usual). > Can we have write access in the meantime then? Most other developers already have write access. You won't get write access before: 1- You change your SF user account name to something more professional. 2- You ask me for it, and we make the mandatory agreement on legal issues. [Personally, I was toying with the idea of moving to a "old" Linus model where contributions would be submitted as patches (but using a SF tracker, in stead of the mailing-list), just to make sure no hot headed developer went and screwed up the CVS repository inadvertently...] > are only a handful of developers. We could set up a cvs-commit mailer > that automatically sends out all changes and who made them. You have to learn to RTFM (or I should say RTFWP [Web Page])... Have you looked at the links at the top left of the www.sablevm.org web page? > I don't *desperately* need write access. Go say that to Linus Torvalds. Ha ha! :-))))) Seriously, SableVM users expect me to make sure write access is given carefully, so that the legal status and the technical stability of the project are not jeopardized. So, first I need to know that whatever you will check-in won't cause problems. There's nothing wrong with setting your own private PRCS repository, which is what I do! PRCS is fantastic for managing local CVS snapshots. Try it. It doesn't create CVS subdirectories, so it doesn't conflict with CVS. :-)) Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 17:24:54
|
On Tue, Mar 18, 2003 at 12:05:24PM -0500, Prof. Etienne M. Gagnon wrote: > The only thing I can do, if you want to put all sort of stuff into > CVS, is to start a "distinct module", sablevm-experimental, that could > live in parallel, where there would be, again, a single trunk, but > where all developers can check-in stuff freely (as long as the code is > licensed appropriately, no non-clean-room contribution as usual). In fact, it would have 2 brances: Trunk & Vendor branch. The latter would track changes in the sablevm module. What do you, and others, think of this? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2003-03-18 18:17:51
|
Prof. Etienne M. Gagnon wrote: >On Tue, Mar 18, 2003 at 11:27:19AM -0500, Chris Pickett wrote: > > >>I agree, CVS only allows for a few different models. However, other >>than the problem of creating a branch every time you want to release, I >>can't really see what's wrong with having short-lived branches. >> >> > >How much development experience do you have on moderately big software >projects? [I seriously want a detailed answer to this question. You >may answer privately, if you think it is more appropriate.] > > Not that much at all, save for 6 months in Japan where I set up a CVS repository / project management system for 100 students, and contributed to the E-Cell project (large-ish simulation project written in C++/python/domain-specific modelling language). I am not a programmer, the largest thing I have written is probably my WIG compiler in 520 at McGill (5000 lines of Java using SableCC, of which I wrote 80%). I didn't do my undergraduate degree in CS (it was biochemistry) and I only started really programming in C a couple of weeks ago. I know Java a lot more than I know C (obviously) and am somewhat familiar with design patterns. Hell, I don't even have Linux installed on my laptop (my only machine) and I do everything using ssh/tty and emacs. All in all, I sux0rz. > >Personally, I do see all kind of problems with short-lived branches >(specially for managing an automatically generated changelog file, >which is necessary to honor the requirements of the LGPL license, in >case you were not aware). > Okay, I did not know that. I have not read the LGPL license, I just know broadly what it entails. I'll read it. > >I don't have time to justify every single little decision of mine. >You will have to learn to live with some of my decisions, or you may >fork your own project. One of these decisions is that will live with >a single trunk, no branches. > > Hey, it's okay. I'm not pushing you for branches. It's a real pain, and I understand that. I'm essentially maintaining a branch in my local repository anyway. >The only thing I can do, if you want to put all sort of stuff into >CVS, is to start a "distinct module", sablevm-experimental, that could >live in parallel, where there would be, again, a single trunk, but >where all developers can check-in stuff freely (as long as the code is >licensed appropriately, no non-clean-room contribution as usual). > > > In fact, it would have 2 brances: Trunk & Vendor branch. The latter > would track changes in the sablevm module. > What do you, and others, think of this? I think that's fine, but what potential problems do you see w.r.t. synchronization? If someone fixes something in the experimental branch, do they submit a patch for it to be included in the non-experimental branch? I have no problem being restricted to not committing anything to the main development module unless explicitly asked. Maybe you want to send an email to the info-cvs list I gave a link to, explaining the current problems and the specifics of our project (# of developers, CVS version, code size, etc.), and see what they have to say about your solution. >>Can we have write access in the meantime then? >> >> > >Most other developers already have write access. You won't get write >access before: >1- You change your SF user account name to something more professional. > > I already did that ... immediately after you asked me ... it's cpickett now (look at the comment I just made in the bug tracker). you can even close those bugs and re-open them if you don't want ihatemcgill to show up in the bug tracker. >2- You ask me for it, and we make the mandatory agreement on legal issues. > > Ok, I'm asking you. I can sign whatever you want me to sign. As for a clean room, I can guarantee that much for sure. >[Personally, I was toying with the idea of moving to a "old" Linus >model where contributions would be submitted as patches (but using a >SF tracker, in stead of the mailing-list), just to make sure no hot >headed developer went and screwed up the CVS repository >inadvertently...] > > > >>are only a handful of developers. We could set up a cvs-commit mailer >>that automatically sends out all changes and who made them. >> >> > >You have to learn to RTFM (or I should say RTFWP [Web Page])... Have >you looked at the links at the top left of the www.sablevm.org web >page? > > sorry, I didn't know there was one. i read so many WP's all the time i forget where things are. my bad. there are so many M's for me to FR right now. >>I don't *desperately* need write access. >> >> > >Go say that to Linus Torvalds. Ha ha! :-))))) > > Okay, I don't need write access at all. It would just make things a bit easier for me. >Seriously, SableVM users expect me to make sure write access is given >carefully, so that the legal status and the technical stability of the >project are not jeopardized. So, first I need to know that whatever >you will check-in won't cause problems. There's nothing wrong with >setting your own private PRCS repository, which is what I do! PRCS is >fantastic for managing local CVS snapshots. Try it. It doesn't >create CVS subdirectories, so it doesn't conflict with CVS. :-)) > > Okay, I can do that. Or maybe I'll switch to using Subversion (since it sounds like you want to try it in the future) Basically, there are two reasons why I would like the sablevm-experimental module: 1) So I can more easily synchronize my changes with other people's changes while still keeping them under version control. The project I am working on is speculative multithreading, and should be fairly independent of other SableVM stuff, and will probably not really break anything except itself. 2) So I can contribute documentation to the source code, as well as to separate documentation files. This is more for the benefit of other developers of course ... if I spend the time to document / understand a file, chances are I don't need to read those comments so much -- but it should help others. Cheers, Chris P.S. I hate debates like this too. I hope we don't ending hating each *other* :-( Not good for collaboration . . . |
|
From: Chris P. <chr...@ma...> - 2003-03-18 18:40:27
|
> > >>The only thing I can do, if you want to put all sort of stuff into >>CVS, is to start a "distinct module", sablevm-experimental, that could >>live in parallel, where there would be, again, a single trunk, but >>where all developers can check-in stuff freely (as long as the code is >>licensed appropriately, no non-clean-room contribution as usual). >> >> >> In fact, it would have 2 brances: Trunk & Vendor branch. The latter >> would track changes in the sablevm module. > >> What do you, and others, think of this? > >I think that's fine, but what potential problems do you see w.r.t. synchronization? If someone fixes something in the experimental branch, do they submit a patch for it to be included in the non-experimental branch? > I meant "module", not "branch" here. |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-18 19:28:08
|
[I think my first version of this message got lost by human error...] On Tue, Mar 18, 2003 at 01:18:09PM -0500, Chris Pickett wrote: > ... If someone fixes something in the experimental branch, do > they submit a patch for it to be included in the non-experimental branch? Yep (until the change to subversion, if it indeed works as intended). > I have no problem being restricted to not committing anything to the main > development module unless explicitly asked. I would say, unless explicitly agreed upon (on the ML or in person). > Maybe you want to send an email to the info-cvs list I gave a link to, > explaining the current problems and the specifics of our project (# of > developers, CVS version, code size, etc.), and see what they have to say > about your solution. If I'm right, some of the cvs developers take now part in subversion development, so no need to tell them about things they already know about. (They do know.) > >1- You change your SF user account name to something more professional. > > > > > I already did that ... immediately after you asked me ... it's cpickett Good. > now (look at the comment I just made in the bug tracker). you can even > close those bugs and re-open them if you don't want ihatemcgill to show > up in the bug tracker. If the bugs are not closed within a few weeks, it might be worth the effort. > >2- You ask me for it, and we make the mandatory agreement on legal issues. > > > > > Ok, I'm asking you. I can sign whatever you want me to sign. As for a > clean room, I can guarantee that much for sure. Search the ML archive for my latest policy on contributions. Usually, no signed documents are involved (I do not require Copyright assignment, as does the FSF). We can discuss the details at our meeting. > Okay, I can do that. Or maybe I'll switch to using Subversion (since it > sounds like you want to try it in the future) Great! This would allow me to get first-hand feedback about it. Please do so. :-) [This would be a good way to test it's braches and merge mechanisms]. Test as much as you can, inluding moving/renaming files, etc., if possible. > > Basically, there are two reasons why I would like the > sablevm-experimental module: > OK. I'll add the module. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X