Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0
<quote who="bwarsaw@users.sourceforge.net">
--- NEW FILE: README.txt --- This is a very rough work in progress. All Mailman 3.x work will occur in this directory under the top level CVS repository. Because I intend to reorganize the source tree, I think it's just better to start fresh. This does however mean that for anything we copy over (and hopefully that will be a good bit of code), we'll lose the CVS history for it.
It might be a bit of extra work, but why not just copy the files around in the repository? History is important! :-)
- Jeff
-- linux.conf.au 2004: Adelaide, Australia http://lca2004.linux.org.au/
"Ah, now we see the violence inherent in the system." - From Monty
Python to ESR, by way of Al Viro
On Sat, 2003-05-24 at 00:37, Jeff Waugh wrote:
It might be a bit of extra work, but why not just copy the files around in the repository? History is important! :-)
Two reasons:
I'm not even sure what the directory structure is going to look like yet, and I don't really know how, if, or which old files will map into new files.
It's a royal PITA to do this when you don't have direct access to the repository.
For now, this is all extremely experimental. I just need a place to check in some noodlings so the code isn't just sitting on my disk.
-Barry
<quote who="Barry Warsaw">
- It's a royal PITA to do this when you don't have direct access to the repository.
Well, that thoroughly nukes it. ;-)
For now, this is all extremely experimental. I just need a place to check in some noodlings so the code isn't just sitting on my disk.
Awesome! Really keen to see / help out where (er, if?) I can. :-)
- Jeff
-- GU4DEC: June 16th-18th in Dublin, Ireland http://www.guadec.org/
"Consensus is whatever the developers remember or agree with." - Paul Vixie, Open Sources
On Sat, 2003-05-24 at 02:12, Jeff Waugh wrote:
Awesome! Really keen to see / help out where (er, if?) I can. :-)
Cool. I'm thinking that once I get the basic framework in place we should open things up so more people can contribute.
-Barry
[Barry Warsaw]
On Sat, 2003-05-24 at 00:37, Jeff Waugh wrote:
It might be a bit of extra work, but why not just copy the files around in the repository? History is important! :-)
Two reasons:
I'm not even sure what the directory structure is going to look like yet, and I don't really know how, if, or which old files will map into new files.
It's a royal PITA to do this when you don't have direct access to the repository.
For now, this is all extremely experimental. I just need a place to check in some noodlings so the code isn't just sitting on my disk.
[ Replying to a 3.5-months-old message... hopefully my response lag time will improve shortly. :-) ]
If there is enough demand for tree reorganization to require using a completely new CVS module, has any thought been given to switching to a revision control system that actually *supports* renames?
There seems to be quite a few of them about, and in particular GNU Arch appears to have gotten a popularity boost recently.
Harald
On Sun, 2003-09-07 at 17:30, Harald Meland wrote:
[ Replying to a 3.5-months-old message... hopefully my response lag time will improve shortly. :-) ]
Yours and mine both! :)
If there is enough demand for tree reorganization to require using a completely new CVS module, has any thought been given to switching to a revision control system that actually *supports* renames?
There seems to be quite a few of them about, and in particular GNU Arch appears to have gotten a popularity boost recently.
Thought about it, but as long as we're on SF and SF uses CVS, it's too much work to switch.
-Barry
[Barry Warsaw]
On Sun, 2003-09-07 at 17:30, Harald Meland wrote:
If there is enough demand for tree reorganization to require using a completely new CVS module, has any thought been given to switching to a revision control system that actually *supports* renames?
Thought about it, but as long as we're on SF and SF uses CVS, it's too much work to switch.
I'm not sure which aspect(s) of "SF uses CVS" you're referring to:
- SF hosts the "official" CVS repository.
- SF has a system for granting project developers commit access to the central repository.
- SF hosts an anonymous access version of the repository.
- SF has routines for gathering "project activity metrics" that are (partly) based on CVS access.
- Users familiar with SF more or less expect all projects hosted there to use CVS.
... or something else?
A complete switch to e.g. GNU Arch (http://www.gnu.org/directory/GNU/arch.html) does not conflict with all of these:
- SF provides both sftp and http access. Arch can do archive (Arch's name for "repository") access (r/w) over sftp, and read-only access over http.
- It is possible to use the same file groups SF uses for CVS access to do Arch commit access (over e.g. sftp). However, with Arch's support for distributed archives, it might not be necessary.
- With Arch, one could either use the devel archive directly (because the same archive could be accessed through both sftp and http), or one could leverage Arch's support for mirroring of archives.
- No good solution here -- but then again, I'm not convinced it really is necessary to "solve" this. I don't think SF's popularity-meter is particularly important to Mailman...
- Well, I think users with such expectations are bound to be wrong sooner or later. :-)
Additionally, a "complete switch" might not be necessary; some projects are using both CVS and Arch simultaneously. These setups typically leave it to the Arch users to do the gatewaying to/from CVS -- but the CVS users are more likely to get into trouble when files/directories are moved around, as such changes will be seen as delete+add operations in CVS.
Finally, there are other systems than Arch our there. In particular, Meta-CVS (http://users.footprints.net/~kaz/mcvs.html) provides an easy (if not backwards compatible) solution to items 1-4 (but still requires users to change their expectations).
Harald
I would assume that Barry is working on the "it ain't broke so don't fix it" principle and he is sufficiently busy that getting real work done is enough to be going on with (like outstanding bug fixes checked and applied to the CVS so that 2.1.3 can be generated and shipped).
If that is the case I would support the view that adopting a new version control approach may not be the most important task currently to hand for the Mailman project leader.
On Monday, September 8, 2003, at 04:16 pm, Harald Meland wrote:
[Barry Warsaw]
On Sun, 2003-09-07 at 17:30, Harald Meland wrote:
If there is enough demand for tree reorganization to require using a completely new CVS module, has any thought been given to switching to a revision control system that actually *supports* renames?
Thought about it, but as long as we're on SF and SF uses CVS, it's too much work to switch.
I'm not sure which aspect(s) of "SF uses CVS" you're referring to:
- SF hosts the "official" CVS repository.
- SF has a system for granting project developers commit access to the central repository.
- SF hosts an anonymous access version of the repository.
- SF has routines for gathering "project activity metrics" that are (partly) based on CVS access.
- Users familiar with SF more or less expect all projects hosted there to use CVS.
... or something else?
A complete switch to e.g. GNU Arch (http://www.gnu.org/directory/GNU/arch.html) does not conflict with all of these:
- SF provides both sftp and http access. Arch can do archive (Arch's name for "repository") access (r/w) over sftp, and read-only access over http.
- It is possible to use the same file groups SF uses for CVS access to do Arch commit access (over e.g. sftp). However, with Arch's support for distributed archives, it might not be necessary.
- With Arch, one could either use the devel archive directly (because the same archive could be accessed through both sftp and http), or one could leverage Arch's support for mirroring of archives.
- No good solution here -- but then again, I'm not convinced it really is necessary to "solve" this. I don't think SF's popularity-meter is particularly important to Mailman...
- Well, I think users with such expectations are bound to be wrong sooner or later. :-)
Additionally, a "complete switch" might not be necessary; some projects are using both CVS and Arch simultaneously. These setups typically leave it to the Arch users to do the gatewaying to/from CVS -- but the CVS users are more likely to get into trouble when files/directories are moved around, as such changes will be seen as delete+add operations in CVS.
Finally, there are other systems than Arch our there. In particular, Meta-CVS (http://users.footprints.net/~kaz/mcvs.html) provides an easy (if not backwards compatible) solution to items 1-4 (but still requires users to change their expectations).
Harald
[Richard Barrett]
I would assume that Barry is working on the "it ain't broke so don't fix it" principle
Well, while I agree with that principle, I'm reading mailman3/README.txt to be yet another phrasing of the conclusion that CVS *is* broken -- at the very least for projects where renames are needed.
and he is sufficiently busy that getting real work done is enough to be going on with (like outstanding bug fixes checked and applied to the CVS so that 2.1.3 can be generated and shipped).
Sure. That means someone else should help out with researching how the "not real work" stuff could be done, in order to make the (necessary, if a rename-supporting VC is needed) learning curve less steep. As a bonus, such usage sketches might reveal which aspects of VC is important to the project -- by letting the project contributors comment on them.
If all contributors are indeed happy with CVS, there is no reason to change, and I'll be happy to spend my "Mailman time" (of which there hasn't been a great deal for some years, but hopefully will be more shortly) on other issues.
Cheers,
Harald
participants (4)
-
Barry Warsaw -
Harald Meland -
Jeff Waugh -
Richard Barrett