FAQ: Why is Drupal still using CVS when X is a much better choice?
Since we're all sick of answering this question every week, I've made an attempt at documenting this here: http://drupal.org/node/289117 If someone has some of the old threads laying around and could help flesh that page out (esp. with "here's where you jump in if you want to change this" stuff), that'd be lovely. -Angie
Thanks ... would you consider retitling it to "How you can help Drupal migrate to a modern RCS."? I think thats more positive. Virtually all agree that the current situation is non ideal. On Wed, Jul 30, 2008 at 12:50 PM, Angela Byron <drupal-devel@webchick.net> wrote:
Since we're all sick of answering this question every week, I've made an attempt at documenting this here:
If someone has some of the old threads laying around and could help flesh that page out (esp. with "here's where you jump in if you want to change this" stuff), that'd be lovely.
-Angie
Moshe Weitzman wrote:
Thanks ... would you consider retitling it to "How you can help Drupal migrate to a modern RCS."? I think thats more positive. Virtually all agree that the current situation is non ideal.
I'd be more than happy to do that if people can start adding enough information about relevant issues, groups, mailing list threads, etc. that tell people how to help, in order to warrant the title change. :) Derek? Chad? Adam? Jakob? -Angie
On Wed, Jul 30, 2008 at 12:04 PM, Angela Byron <drupal-devel@webchick.net> wrote:
Moshe Weitzman wrote:
Thanks ... would you consider retitling it to "How you can help Drupal migrate to a modern RCS."? I think thats more positive. Virtually all agree that the current situation is non ideal.
I'd be more than happy to do that if people can start adding enough information about relevant issues, groups, mailing list threads, etc. that tell people how to help, in order to warrant the title change. :)
Derek? Chad? Adam? Jakob?
-Angie
I'm not sure if, practically speaking, there is anything any one or two people can do. I've seen almost no support in either IRC or various mailing lists by the key infrastructure players for SVN, and I'm not sure saying something like "we could move to XXX if only there were GUI clients available, so you could help by writing one of those" is very helpful. For the moment, I think the first major obstacle is getting the Version Control API functional and writing the tie ins with the project module, which Angie already mentioned in the handbook page (the stuff at http://groups.drupal.org/node/8102). But really, even more important than that is the port of project* to D6. Once all of this is done I think the next logical step would be picking a new RCS, because it wouldn't make sense to, in parallel, write backends, rewrite help, etc. if we didn't know what RCS we were going to go to. I really have no idea who would make a decision like that. Perhaps whomever that is (or whatever group of people that is) should raise their hands and explain what kind of argument would need to be made for them to be convinced. How many GUI clients need to be available, what platforms, etc.? Without any solid information on who makes such a decision and what would cause them to agree to move from CVS, I'm not sure that we can give solid information on how people could help. Also, just saying that the infrastructure team decides is not helpful, because clearly not all "members" of the infrastructure team are equal. Adam
(This discussion is more relevant in this thread -- the other thread was really just about a document someone wrote describing how to use git and CVS together...) On Jul 30, 2008, at 8:09 PM, Sam Boyer wrote:
I've taken over Version Control API from Jakob. I hope to start work with it shortly before Szeged.
This is indeed good news (and news to me). Note to others who care about this topic: this isn't really a 1- person job. So, don't let Sam's offer stop you from also stepping forward to volunteer. ;) Also, what Adam wrote is still incredibly relevant for the drupal.org implications of versioncontrol API and friends: A) How do "we" decide which RCS to move to, assuming everything else is in place? B) Who's the "we" who makes this decision? Further, I'd add the following for everyone to chew over: C) Do we move everything at once, or do we just move core to the new thing, and leave contrib with CVS as an interim measure to prevent large-scale, simultaneous catastrophe on all sides? ;) D) Do we leave open the possibility that each project on d.o can choose if it wants CVS or XXX? Do we provide multiple alternatives (svn + git?). I'm 95% sure that the original specs for versioncontrol API and the intended interface with project* left this as an option. So, even if it's not technically possible now, it should be by the time everything is all tied together. The question is do we even want to turn that on on d.o, or not. If we can all be respectful and manage to prevent this from becoming Yet Another Bikeshed Thread, the chances of any of this actually coming into existence will be higher. In fact, I'd recommend that no one attempts to answer any of these questions for at least 24 hours after reading this message. Just let it soak in before you say what you think. (C) won't need to be answered for at least 3 months, probably longer. (A), (B) and (D) should be answered sooner, but not immediately. Cheers, -Derek (dww)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb:
Also, what Adam wrote is still incredibly relevant for the drupal.org implications of versioncontrol API and friends:
A) How do "we" decide which RCS to move to, assuming everything else is in place?
Note that I am not convinced that we need to move at all. :p
B) Who's the "we" who makes this decision?
The drupal.org infratructure team based on the input of the developer community. Any change to the core repo is basically dependend on Dries' approval.
Further, I'd add the following for everyone to chew over:
C) Do we move everything at once, or do we just move core to the new thing, and leave contrib with CVS as an interim measure to prevent large-scale, simultaneous catastrophe on all sides? ;)
I think that assuming we 1) want to move at all 2) manage to agree on a system to move to and 3) Dries agrees with this would be a good plan.
D) Do we leave open the possibility that each project on d.o can choose if it wants CVS or XXX?
Certainly not. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIkXYPfg6TFvELooQRAqnlAJ4tKEYd6OakkbDSdjkRob9OZKAjbQCfXyp6 xFhfQiIoedGBXAbeh0gUBP0= =jQfY -----END PGP SIGNATURE-----
On Thu, Jul 31, 2008 at 3:21 AM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Derek Wright schrieb:
B) Who's the "we" who makes this decision?
The drupal.org infratructure team based on the input of the developer community.
This is the kind of answer I expected to be provided, but I think it's way to vague. Who is the drupal.org infrastructure team? People with accounts on infrastructure.drupal.org? People with some kind of shell access to the drupal.org infrastructure? If either of these were the actual criteria, then I would not be considered to be on the team, yet in my own mind I do consider myself part of the team. How would the team go about this decision? A simple vote? Does the majority rule, or does it need to be unanimous? I know that the drupal community itself is quite decentralized, and that we probably don't have answers to a lot of the questions above, maybe because such things haven't come up before. But, in my opinion, this decentralization makes it hard to get a lot of things done, since it's never clear who would make the decision and how. The drupal.org redesign is, from my perspective, caught in a similar situation. Even if the answer of "who makes the decision to switch to a new RCS" was "Gerhard Killesreiter", at least it would be more clear what needs to be done to switch. As is, I still think it's totally unclear. Adam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Light schrieb:
On Thu, Jul 31, 2008 at 3:21 AM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Derek Wright schrieb:
B) Who's the "we" who makes this decision? The drupal.org infratructure team based on the input of the developer community.
This is the kind of answer I expected to be provided, but I think it's way to vague.
Kieran recently explained what "infrastructure team" means: http://lists.drupal.org/private/infrastructure/2008-July/012056.html
How would the team go about this decision? A simple vote? Does the majority rule, or does it need to be unanimous?
We'd need to reach an agreement in a similar way that we do reach agreements about patches that go into Drupal: By discussion among experts.
Even if the answer of "who makes the decision to switch to a new RCS" was "Gerhard Killesreiter", at least it would be more clear what needs to be done to switch. As is, I still think it's totally unclear.
Since I am ultimately responsible for running drupal.org I of course wouldn't agree to running a RCS that would likely exceed our servers capabilities or put a lot of work on the table of the infrastructure team by creating support requests. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIkauIfg6TFvELooQRAkcSAJ9v7YAIkZpEgnmw5kEgdwVFlpwGiACfXpnV 52dAH3OzsWjx7GdEjE1QrFA= =4I/N -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
Kieran recently explained what "infrastructure team" means: Yay!
http://lists.drupal.org/private/infrastructure/2008-July/012056.html Ah. Password protected :(
-- Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Thu Jul 31 2008 5:40:40 am Adrian Simmons wrote:
Gerhard Killesreiter wrote:
Kieran recently explained what "infrastructure team" means:
Yay!
http://lists.drupal.org/private/infrastructure/2008-July/012056.html
Ah. Password protected :(
Sign up to the mail list, then you'll have access to the archives. -- Jason Flatt http://www.oadaeh.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 15; Cramer, 13; Travis, 11; Angela; Harry, 8; and William, 2) Linux User: http://www.kubuntu.org/ Drupal Fanatic: http://drupal.org/
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better. And back to Drupal contrib, at least with a central repo you can have some central control trying to keep order but with a DRCS all bets are off. Check contrib CVS root for all the crap our CVS challenged contributors add there and think what would ensue with a DRCS. It's highly debatable that the most serious of our problems, namely understanding RCS would be solved by any DRCS. You sure want to explain multiple heads for one or patch algebra for another? How does 140+ commands sound (and then some has one or two superb powerful switches...) This is a terrible mess. Now, with SVN we wll need a script to stop tagged things from being changed because they are not immutable as they were in CVS -- but this is readily available and this is the only problem I am aware of. SVN concepts are mapping much better to reality -- one dir per branch/tag. Makes it (much) easier to understand. You already keep a separate directory for your branches so that's how the repository looks like, easy! Thus it _will_ solve some problems -- another problem with DRCS that it does nto solve the problems we have :) SVN tools are available. SVN is mature and documentation is plentiful. svn 1.5 added merge tracking for (much) better team work. Feature foo and bar might be unavailable for SVN but I can not care , we need something that we, we all of the Drupal community can use. Once the reboot of my life is complete (read: September) I will rejoin the moving effort and help.
On 31 Jul 2008, at 12:42 PM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better.
Wow. that's quite a turn around =) I also like SVN over the others in that it removes complexity instead of adds more.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Rossouw schrieb:
On 31 Jul 2008, at 12:42 PM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better.
Wow. that's quite a turn around =)
I also like SVN over the others in that it removes complexity instead of adds more.
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIkZxafg6TFvELooQRAph7AKC5Nxz9w7+daWj+qqUnWPJFpF+mtwCcCtgj UzCtAaieYuBfgsJOck3O2Fc= =kfzb -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving. That's absolutely true for Drupal core :)
But it's not true for contrib. And what we I think we all mean when we talk about drupal.org moving to a different VCS is *contrib moving*. Karoly Negyesi wrote:
SVN tools are available. SVN is mature and documentation is plentiful. svn > 1.5 added merge tracking for (much) better team work.
I'd add that the two most attractive features of DVCS systems - better merge algorithms and offline commits - can be achieved by people using SVK in conjunction with SVN. Derek Wright wrote:
A) How do "we" decide which RCS to move to Someone could sit down with a list of our needs and do a point by point analysis of what the various VCS and DVCS would provide or not but really Karoly hits the nail on the head: "If we move, we move to SVN". There isn't another viable choice. So that's A) dealt with ;)
D) Do we leave open the possibility that each project on d.o can choose if it wants CVS or XXX? Do we provide multiple alternatives (svn + git?). Someone can correct me but I think all of the DVCS possibilities can integrate quite well with SVN, once you've provided SVN there's little benefit to providing anything else.
Just imagine this is written in a few months:
C) Do we move everything at once, or do we just move core to the new thing, and leave contrib with CVS as an interim measure to prevent large-scale, simultaneous catastrophe on all sides?
Core doesn't *need* to move, there's no benefit to moving it first, it doesn't even provide much of a comparison to contrib in terms of numbers of commiters and their competence. I think really you'd have to select a subset of contrib modules (I'm sure there'd be no shortage of volunteers) to move first. -- Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>
So I'll be writing a bunch of responses to various items in this thread, but let me just put this out there as a caveat: right now and for at least the immediate future, I don't consider my newfound role as Version Control API maintainer to include advocacy for switching d.o to any particular RCS. In my mind, there are lots of interesting things to think about, but I've got coding to do before it's much more than conjecture. Personally, I can think of very legitimate arguments for & against a) staying with CVS, b) moving to SVN, c) moving to git, hg, or bzr. So for the moment, I'm hoping to just provide concrete information. On Thu, 2008-07-31 at 15:01 +0100, Adrian Simmons wrote:
Gerhard Killesreiter wrote:
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving. That's absolutely true for Drupal core :)
But it's not true for contrib. And what we I think we all mean when we talk about drupal.org moving to a different VCS is *contrib moving*.
It's true - core operates under quite a different paradigm from contrib, and IMO the conceptual clash in the contrib paradigm v. CVS is more pronounced than in core paradigm v. CVS.
Karoly Negyesi wrote:
SVN tools are available. SVN is mature and documentation is plentiful. svn > 1.5 added merge tracking for (much) better team work.
http://subversion.tigris.org/svn_1.5_releasenotes.html Merge tracking is definitely one of the biggest single selling points of SVN vs. CVS, although it's still orders of magnitude less powerful than git. But IMO, that's moot unless/until someone does some pretty thorough investigating of svn 1.5's in-practice interoperability with svn 1.4. That means please don't regurgitate the table at the link I just posted; we can all read, I mean how it ACTUALLY works =)
I'd add that the two most attractive features of DVCS systems - better merge algorithms and offline commits - can be achieved by people using SVK in conjunction with SVN.
These are indeed two very attractive features - although maybe not the _most_ attractive, IMO - of a distributed vcs. svk also has the added benefit of reducing the amount of overhead data that's contained in your .svn directory, which can (especially for large projects with long histories) end up being quite significant. But as I said before, git's merge capabilities are in a class of their own, stemming from the fact that git is a content-addressable filesystem. Sort of along these lines, and partially as an additional response to chx, another feature that's interesting in the list of items that svn 1.5 adds is 'pegs', which improve on svn:externals a bit. However, svn:externals itself is pretty inflexible, so...
Derek Wright wrote:
A) How do "we" decide which RCS to move to Someone could sit down with a list of our needs and do a point by point analysis of what the various VCS and DVCS would provide or not but really Karoly hits the nail on the head: "If we move, we move to SVN". There isn't another viable choice. So that's A) dealt with ;)
D) Do we leave open the possibility that each project on d.o can choose if it wants CVS or XXX? Do we provide multiple alternatives (svn + git?).
Multiple alternatives is a...complicated question. I don't yet know enough to say where or how the reconciling of the different systems would occur. My suspicion, though, is that it would be a nasty example of the drupal community special brand of 'let's roll-our-own!' hubris to try to reconcile them ourselves; chances are, if we were to do this, we'd build the base with git, use its native capabilities to wrap svn, and have the project* system speak to git.
Someone can correct me but I think all of the DVCS possibilities can integrate quite well with SVN, once you've provided SVN there's little benefit to providing anything else.
Nope, no need to correct you on this one. Of hg, bzr, git, the only one I'm not sure about providing good svn interoperability is hg. But I'm pretty sure it should be largely the same.
Just imagine this is written in a few months:
C) Do we move everything at once, or do we just move core to the new thing, and leave contrib with CVS as an interim measure to prevent large-scale, simultaneous catastrophe on all sides?
Core doesn't *need* to move, there's no benefit to moving it first, it doesn't even provide much of a comparison to contrib in terms of numbers of commiters and their competence. I think really you'd have to select a subset of contrib modules (I'm sure there'd be no shortage of volunteers) to move first.
I'm in general conceptual agreement here, but there are very real questions about how we'd organize the svn repo(s) that we'd need to answer before even considering such an experiment. There are good ways to migrate CVS => SVN, and there are bad ways...but they all turn into nightmares very quickly if you don't have a very clear vision of how you organize your svn repo(s) on the other side. cheers, Sam
Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adrian Rossouw schrieb:
On 31 Jul 2008, at 12:42 PM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better. Wow. that's quite a turn around =)
I also like SVN over the others in that it removes complexity instead of adds more.
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving.
SVN provides a few advantages that make it compelling: 1. Security. pserver authentication is horribly, horribly insecure. 2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers. 3. The ability to remove directories without having to post a support request to the repository maintainers. 4. Much, much more intuitive commands. Compare: cvs tag -d DRUPAL-5--1-0 svn remove tags/DRUPAL-5--1-0 cvs up -dPC filename.inc svn revert filename.inc 5. Spend some time browsing through http://drupal.org/project/issues?projects=107028&components=CVS, and you see an awful lot of requests there that wouldn't be there if we were using SVN. For example, it's amazing how often "I need a tag deleted" comes up, because people can't figure out the command to do it. A lot of others are "D'oh. I accidentally committed something somewhere I didn't mean to, and now I want to (re)move it. I can't. Help?" So the support burden on our repository admins (after the initial bout of total confusion, of course ;)) would be remarkably less. 6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;) 7. The SVN community is completely awesome and helpful. I've asked some pretty 'n00b' questions in #svn and always been treated not only with respect, but with a 20-minute answer to my problem. However, the one thing about SVN that terrifies the living Hell out of me is the fact that there is no such thing as a tag. There are only branches, and branches that you don't commit things to (wink wink) are "tags". Judging by the number of people who screw this up now, I can't imagine the utter chaos we'd have if the "stable" 5.x-1.0 release of a module could change on a whim. However, it might be that we could do some funky pre-commit scripts or something to enforce the CVS idea of a tag. If we go down this route, I'm sure the ever-awesome SVN community could help us figure it out. :) -Angie
On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
5. Spend some time browsing through http://drupal.org/project/ issues?projects=107028&components=CVS, and you see an awful lot of requests there that wouldn't be there if we were using SVN. For example, it's amazing how often "I need a tag deleted" comes up, because people can't figure out the command to do it.
For the record, this has *nothing* to do with the (D)VCS of choice, but everything to do with people's lack of understanding the basics of release management. The answer to all these questions isn't: - it's "cvs tag -d DRUPAL-5--1-1-ALPHA-CHICKEN", silly, not "cvs remove". The answer is almost always: - You already tagged and released that version. Your alpha chicken is loose in the wild. Your only recourse now is to make a beta chicken or make a real release. Please RTFM about "Fixing releases": http://drupal.org/node/128614 Cheers, -Derek (dww)
On Thu, Jul 31, 2008 at 12:05 PM, Derek Wright <drupal@dwwright.net> wrote:
- You already tagged and released that version. Your alpha chicken is loose in the wild. Your only recourse now is to make a beta chicken or make a real release.
I find that I really like free-range alpha chicken with barbecue sauce, but that's just me. ;-) -- ..chris
On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
1. Security. pserver authentication is horribly, horribly insecure.
I think the security problems will be just as bad with SVN given the OSUOSL infrastructure. There's a way to do CVS securely (over ssh), which is basically equivalent to what we'd have to do to actually make SVN secure (as far as I know), but the OSUOSL side of this question has been "won't fixed" because it would involve giving (extremely limited) shell access to every CVS account holder: http://drupal.org/node/199412 I'll admit I haven't closely studied SVN's various security models, so I could be wrong about this, but on the surface, I think this particular argument is a red herring, since we couldn't configure SVN any more securely than we can configure CVS. If anyone can provide a link to a clear document explaining how to configure SVN more securely than pserver if you don't actually have accounts and ssh keys for everyone, please do so.
2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers.
Yeah, this is a minor pain in the ass (my ass, to be precise, since I don't think anyone else has ever fielded one of the cvs_rename issues). But, I've been documenting the process in various issues and hopefully others could pick up some of this (relatively small, in the scheme of things) support load.
3. The ability to remove directories without having to post a support request to the repository maintainers.
The people who botch this aren't the ones who notice and fix it, anyway. Usually killes or I find the cruft strewn about various places in the contributions repo directory tree that don't belong and we clean it up. Sometimes someone else points it out first, but even if we had a different VCS, cleaning up stuff like this would take the intervention of a repository admin (because of access control reasons, if nothing else).
4. Much, much more intuitive commands.
This doesn't matter if people already know the CVS commands. If they don't, we've got handouts, handbooks, screencasts, DrupalCon talks, off-site writeups, and more, explaining what they need to know... And, as Earl pointed out, the most important commands for tagging and branching are arguably much less intuitive, and those are the ones people seem to have the most trouble with. 5. answered in another message...
6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;)
Agreed. This is about the only feature I'd actually be psyched about. And, making the ~10% of developers that would be psyched about this happy doesn't outweigh the huge costs (and the "terrifies the living Hell out of me" problem of SVN's notion of tags) of a switch.
7. The SVN community is completely awesome and helpful.
Hey, what are you trying to say? You think I'm neither awesome nor helpful? ;) Not to butt heads with the contributor of the year, but I don't think any of these reasons are actually "compelling". ;) Cheers, -Derek (dww)
On Thu, 2008-07-31 at 10:46 -0700, Derek Wright wrote:
On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
1. Security. pserver authentication is horribly, horribly insecure.
I think the security problems will be just as bad with SVN given the OSUOSL infrastructure. There's a way to do CVS securely (over ssh), which is basically equivalent to what we'd have to do to actually make SVN secure (as far as I know), but the OSUOSL side of this question has been "won't fixed" because it would involve giving (extremely limited) shell access to every CVS account holder:
I'll admit I haven't closely studied SVN's various security models, so I could be wrong about this, but on the surface, I think this particular argument is a red herring, since we couldn't configure SVN any more securely than we can configure CVS. If anyone can provide a link to a clear document explaining how to configure SVN more securely than pserver if you don't actually have accounts and ssh keys for everyone, please do so.
So let me quickly just respond here to say that, in fact, SVN is almost terrifyingly easy to set up securely using SSH. No need for shell accounts per user. Obviously using ssh keys means that we'd need to _get_ those public keys from people in the first place, and doing so would also be a very real change for all contributors: either you learn SSH, or you can't contribute to drupal.
2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers.
Yeah, this is a minor pain in the ass (my ass, to be precise, since I don't think anyone else has ever fielded one of the cvs_rename issues). But, I've been documenting the process in various issues and hopefully others could pick up some of this (relatively small, in the scheme of things) support load.
3. The ability to remove directories without having to post a support request to the repository maintainers.
The people who botch this aren't the ones who notice and fix it, anyway. Usually killes or I find the cruft strewn about various places in the contributions repo directory tree that don't belong and we clean it up. Sometimes someone else points it out first, but even if we had a different VCS, cleaning up stuff like this would take the intervention of a repository admin (because of access control reasons, if nothing else).
4. Much, much more intuitive commands.
This doesn't matter if people already know the CVS commands. If they don't, we've got handouts, handbooks, screencasts, DrupalCon talks, off-site writeups, and more, explaining what they need to know... And, as Earl pointed out, the most important commands for tagging and branching are arguably much less intuitive, and those are the ones people seem to have the most trouble with.
5. answered in another message...
6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;)
Agreed. This is about the only feature I'd actually be psyched about. And, making the ~10% of developers that would be psyched about this happy doesn't outweigh the huge costs (and the "terrifies the living Hell out of me" problem of SVN's notion of tags) of a switch.
7. The SVN community is completely awesome and helpful.
Hey, what are you trying to say? You think I'm neither awesome nor helpful? ;)
Not to butt heads with the contributor of the year, but I don't think any of these reasons are actually "compelling". ;)
Cheers, -Derek (dww)
Hi All, On Thu, Jul 31, 2008 at 10:50 AM, Sam Boyer <drupal@samboyer.org> wrote:
On Thu, 2008-07-31 at 10:46 -0700, Derek Wright wrote:
On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
1. Security. pserver authentication is horribly, horribly insecure.
I think the security problems will be just as bad with SVN given the OSUOSL infrastructure. There's a way to do CVS securely (over ssh), which is basically equivalent to what we'd have to do to actually make SVN secure (as far as I know), but the OSUOSL side of this question has been "won't fixed" because it would involve giving (extremely limited) shell access to every CVS account holder:
I'll admit I haven't closely studied SVN's various security models, so I could be wrong about this, but on the surface, I think this particular argument is a red herring, since we couldn't configure SVN any more securely than we can configure CVS. If anyone can provide a link to a clear document explaining how to configure SVN more securely than pserver if you don't actually have accounts and ssh keys for everyone, please do so.
So let me quickly just respond here to say that, in fact, SVN is almost terrifyingly easy to set up securely using SSH. No need for shell accounts per user. Obviously using ssh keys means that we'd need to _get_ those public keys from people in the first place, and doing so would also be a very real change for all contributors: either you learn SSH, or you can't contribute to drupal.
Actually, an even easier method is to setup SVN access over https - http://gentoo-wiki.com/HOWTO_Apache2_with_subversion_SVN_and_DAV This needs no shell accounts or even SSH keys and can authenticate any way apache can. Thanks! - Owen
On Thu, 2008-07-31 at 10:54 -0700, Owen Barton wrote:
Hi All,
On Thu, Jul 31, 2008 at 10:50 AM, Sam Boyer <drupal@samboyer.org> wrote: On Thu, 2008-07-31 at 10:46 -0700, Derek Wright wrote: > On Jul 31, 2008, at 9:40 AM, Angela Byron wrote: > > > 1. Security. pserver authentication is horribly, horribly insecure. > > I think the security problems will be just as bad with SVN given the > OSUOSL infrastructure. There's a way to do CVS securely (over ssh), > which is basically equivalent to what we'd have to do to actually > make SVN secure (as far as I know), but the OSUOSL side of this > question has been "won't fixed" because it would involve giving > (extremely limited) shell access to every CVS account holder: > > http://drupal.org/node/199412 > > I'll admit I haven't closely studied SVN's various security models, > so I could be wrong about this, but on the surface, I think this > particular argument is a red herring, since we couldn't configure SVN > any more securely than we can configure CVS. If anyone can provide a > link to a clear document explaining how to configure SVN more > securely than pserver if you don't actually have accounts and ssh > keys for everyone, please do so.
So let me quickly just respond here to say that, in fact, SVN is almost terrifyingly easy to set up securely using SSH. No need for shell accounts per user. Obviously using ssh keys means that we'd need to _get_ those public keys from people in the first place, and doing so would also be a very real change for all contributors: either you learn SSH, or you can't contribute to drupal.
Actually, an even easier method is to setup SVN access over https - http://gentoo-wiki.com/HOWTO_Apache2_with_subversion_SVN_and_DAV This needs no shell accounts or even SSH keys and can authenticate any way apache can.
Thanks! - Owen
Yep, https is also an option. I've not worked as extensively with it as I have with ssh-based svn, but it does obviate the need for ssh keys from everyone. It is a bit more intensive than svn+ssh. http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.serverconfig
On Thu, 31 Jul 2008 13:05:16 -0500, Sam Boyer <drupal@samboyer.org> wrote:
Actually, an even easier method is to setup SVN access over https - http://gentoo-wiki.com/HOWTO_Apache2_with_subversion_SVN_and_DAV This needs no shell accounts or even SSH keys and can authenticate any way apache can.
Thanks! - Owen
Yep, https is also an option. I've not worked as extensively with it as I have with ssh-based svn, but it does obviate the need for ssh keys from everyone. It is a bit more intensive than svn+ssh.
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.serverconfig
Sam, we use the HTTPS version at Palantir. :-) (I didn't set it up, but it's worked fine for us.) --Larry Garfield
On 31 Jul 2008, at 7:46 PM, Derek Wright wrote:
I think the security problems will be just as bad with SVN given the OSUOSL infrastructure. There's a way to do CVS securely (over ssh), which is basically equivalent to what we'd have to do to actually make SVN secure (as far as I know), but the OSUOSL side of this question has been "won't fixed" because it would involve giving (extremely limited) shell access to every CVS account holder:
Umm. i think this issue is the same as running apache with fastcgi and suexec (the only really secure way to do multisite, so that each site has it's own user account owning the files). This would probably involve something like using PAM and mysql. I'd definitely be keen to learn more about how this can be solved.
On Thu, 31 Jul 2008 10:46:33 -0700 Derek Wright <drupal@dwwright.net> wrote:
On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
1. Security. pserver authentication is horribly, horribly insecure.
I think the security problems will be just as bad with SVN given the OSUOSL infrastructure. There's a way to do CVS securely (over ssh), which is basically equivalent to what we'd have to do to actually make SVN secure (as far as I know), but the OSUOSL side of this question has been "won't fixed" because it would involve giving (extremely limited) shell access to every CVS account holder:
Not that this is going to change any of your previously stated points but svn works *lovely* over https[*] and that's pretty slick if you've to deal with firewalls too. Anyway I didn't know that people could commit over a completely insecure channel as pserver. Is it? I'd say that while svn will make *my* life easier and while I do see advantages in drcs, they aren't as mature as they should be right now (not just the tools but the adoption etc...) and other than uuuh well pserver auth, I don't see any reason to move from cvs to * NOW. I think anyway that a drcs could have a great influence over the development process and the community IF handled with care and consciousness. Building up a good plan and understanding how a drcs may influence development and community requires time so I think it should be something to keep in mind right now. [*] actually it works over webdav(s) and once you've webdav you could think about other interesting applications inside drupal infrastructure. Other than "modernity" when I had to chose my rcs of choice ease of installation over a secure protocol and friendliness to firewall were the top reasons I chose svn over cvs. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Derek Wright wrote:
On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
1. Security. pserver authentication is horribly, horribly insecure.
I think the security problems will be just as bad with SVN given the OSUOSL infrastructure. There's a way to do CVS securely (over ssh), which is basically equivalent to what we'd have to do to actually make SVN secure (as far as I know), but the OSUOSL side of this question has been "won't fixed" because it would involve giving (extremely limited) shell access to every CVS account holder:
I'll admit I haven't closely studied SVN's various security models, so I could be wrong about this, but on the surface, I think this particular argument is a red herring, since we couldn't configure SVN any more securely than we can configure CVS. If anyone can provide a link to a clear document explaining how to configure SVN more securely than pserver if you don't actually have accounts and ssh keys for everyone, please do so.
As others mentioned, https://svn.drupal.org/.../. I agree SSH accounts/private keys are a huge mess and would reduce our contributor pool to about 20 people. My #1 priority in a move to a new VCS would be "Encourage *more* contributors, not fewer" so I'm also -1 to complicated authentication schemes.
2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers.
Yeah, this is a minor pain in the ass (my ass, to be precise, since I don't think anyone else has ever fielded one of the cvs_rename issues). But, I've been documenting the process in various issues and hopefully others could pick up some of this (relatively small, in the scheme of things) support load.
Fair enough. My #2 priority in a move to a new VCS is "Make Derek's life easier," and I thought this was more of a pain in the ass than it apparently is.
3. The ability to remove directories without having to post a support request to the repository maintainers.
The people who botch this aren't the ones who notice and fix it, anyway. Usually killes or I find the cruft strewn about various places in the contributions repo directory tree that don't belong and we clean it up. Sometimes someone else points it out first, but even if we had a different VCS, cleaning up stuff like this would take the intervention of a repository admin (because of access control reasons, if nothing else).
Fair enough.
4. Much, much more intuitive commands.
This doesn't matter if people already know the CVS commands. If they don't, we've got handouts, handbooks, screencasts, DrupalCon talks, off-site writeups, and more, explaining what they need to know... And, as Earl pointed out, the most important commands for tagging and branching are arguably much less intuitive, and those are the ones people seem to have the most trouble with.
I think a lot of this can be solved with a pointer to http://svnbook.red-bean.com/ which is an *excellent* and free resource that covers everything from "What is version control?" to "Crazy advanced crap you don't need to know about." This resource is much more comprehensive and complete than anything that we've managed to put together in the hundreds of hours we've spent writing docs ourselves. :\ And I mean this with the greatest respect, and also as someone who's put a bunch of elbow grease into the existing documentation, as you know. I'm officially putting my hat into the ring for helping to upgrade existing docs if we move to SVN. I can't make that promise with DVCS because I am totally new to it, though.
6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;)
Agreed. This is about the only feature I'd actually be psyched about. And, making the ~10% of developers that would be psyched about this happy doesn't outweigh the huge costs (and the "terrifies the living Hell out of me" problem of SVN's notion of tags) of a switch.
I've been told by Sam Boyer that I am officially On Crack about the terrifying part, so I'll leave it to him to refute me. ;)
7. The SVN community is completely awesome and helpful.
Hey, what are you trying to say? You think I'm neither awesome nor helpful? ;)
Not to butt heads with the contributor of the year, but I don't think any of these reasons are actually "compelling". ;)
No, no, no! You are *extremely* awesome and helpful! You are also just one guy, and seem to be the main person fielding all of the fall-out from using CVS. I don't like that situation, and from the exasperation you have communicated in the past about you being "the guy" who has to deal wth all the support requests, I gather that you don't either. Every Drupal shop that I'm aware of (and we've worked with most of them) only uses CVS to maintain modules/themes on drupal.org. All of their internal and client projects happen in a SVN repository (with maybe 2% on something fancier like Git). So we have a tremendous amount of in-community knowledge about how SVN works that can be leveraged to off-set support requests that end up falling solely on your shoulders. Additionally, based on my experience, #cvs has about 10 people in it. If I ask a question, it might literally be a day before I get an answer, if ever. So I end up asking in #drupal, or on the issue queue. #svn has about 200 people in it. If I ask a question, suddenly 8 people chime in to answer it, give me pointers to resources for additional information, and also give me some tips I might not have thought of before. I don't need to ask in #drupal or the issue queue, because my problem is solved already. So, let's try this again. ;) The compelling reasons for SVN are: 1. Passwords not passed over the wire in plain-text. :P 2. Empowerment of users to do minor things like renaming files and directories without bugging Derek. :D 3. Greatly increasing the pool of people that has knowledge about how to use and setup the revision control system we switch to, so Derek doesn't have to do everything. :D 4. Being able to leverage outside support materials, such as excellent online documentation and real-time support on IRC. Are those better? :) -Angie
I'll admit I haven't closely studied SVN's various security models, so I could be wrong about this, but on the surface, I think this particular argument is a red herring, since we couldn't configure SVN any more securely than we can configure CVS. If anyone can provide a link to a clear document explaining how to configure SVN more securely than pserver if you don't actually have accounts and ssh keys for everyone, please do so.
Sure. The usual configuration is that SVN is provided by an Apache module (mod_dav and mod_dav_svn) usually over HTTPS so that passwords are not sniffable and mod_authz_svn provides access control. The documentation for this is http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html .
2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers.
Yeah, this is a minor pain in the ass (my ass, to be precise, since I don't think anyone else has ever fielded one of the cvs_rename issues). But, I've been documenting the process in various issues and hopefully others could pick up some of this (relatively small, in the scheme of things) support load.
Such a rename breaks every conversion tool out there because it is, let's face it, a hack. A clever, useful hack but a hack.
6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;)
Agreed. This is about the only feature I'd actually be psyched about. And, making the ~10% of developers that would be psyched about this happy doesn't outweigh the huge costs (and the "terrifies the living Hell out of me" problem of SVN's notion of tags) of a switch.
Sure. But it kills the use "foo DRCS instead" argument. And yes it is indeed possible to grab a mirror of an SVN repo with SVK and then work locally and then push-pull to your hearts' content.
7. The SVN community is completely awesome and helpful.
Hey, what are you trying to say? You think I'm neither awesome nor helpful? ;)
You are on and they are many and yes they are helpful. And there are overlaps already.
Not to butt heads with the contributor of the year, but I don't think any of these reasons are actually "compelling". ;)
To me the compelling idea is that instead of cvs tag -b DRUPAL-7--1 we can say svn copy /contributions/HEAD/modules/foo /contributions/DRUPAL-7--1/modules/foo/ It's SO much easier to explain this because this is what you have on your hard drive. The cvs tag/branch essentially means virtual directories meaning an abstraction layer which people need to comprehend. Here you have files directories and nothing virtual. (Let's not fight now the actual paths we can discuss how to lay out our repo). I find THIS a very compelling reason. Feel free to say "nah you are full of hot air" but please tell me why. I know someone mentioned the svn:externals support. Now, that is a MAJOR feature that might even get some money from concerned Drupal shops (hey, I can dream, can't I?) because it makes their life much easier. http://weierophinney.net/matthew/archives/132-svnexternals.html Derek complained about SVN naive tags. I said that a solution for immutable tags is already readily available: http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/svnperms.conf.examp... says tags/[^/]+/ = *(add) and there we are. I can ask around for other solutions.
I'll admit I haven't closely studied SVN's various security models, so I could be wrong about this, but on the surface, I think this particular argument is a red herring, since we couldn't configure SVN any more securely than we can configure CVS. If anyone can provide a link to a clear document explaining how to configure SVN more securely than pserver if you don't actually have accounts and ssh keys for everyone, please do so.
Sure. The usual configuration is that SVN is provided by an Apache module (mod_dav and mod_dav_svn) usually over HTTPS so that passwords are not sniffable and mod_authz_svn provides access control. The documentation for this is http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html .
2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers.
Yeah, this is a minor pain in the ass (my ass, to be precise, since I don't think anyone else has ever fielded one of the cvs_rename issues). But, I've been documenting the process in various issues and hopefully others could pick up some of this (relatively small, in the scheme of things) support load.
Such a rename breaks every conversion tool out there because it is, let's face it, a hack. A clever, useful hack but a hack.
6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;)
Agreed. This is about the only feature I'd actually be psyched about. And, making the ~10% of developers that would be psyched about this happy doesn't outweigh the huge costs (and the "terrifies the living Hell out of me" problem of SVN's notion of tags) of a switch.
Sure. But it kills the use "foo DRCS instead" argument. And yes it is indeed possible to grab a mirror of an SVN repo with SVK and then work locally and then push-pull to your hearts' content.
7. The SVN community is completely awesome and helpful.
Hey, what are you trying to say? You think I'm neither awesome nor helpful? ;)
You are on and they are many and yes they are helpful. And there are overlaps already.
Not to butt heads with the contributor of the year, but I don't think any of these reasons are actually "compelling". ;)
To me the compelling idea is that instead of cvs tag -b DRUPAL-7--1 we can say svn copy /contributions/HEAD/modules/foo /contributions/DRUPAL-7--1/modules/foo/ It's SO much easier to explain this because this is what you have on your hard drive. The cvs tag/branch essentially means virtual directories meaning an abstraction layer which people need to comprehend. Here you have files directories and nothing virtual. (Let's not fight now the actual paths we can discuss how to lay out our repo). I find THIS a very compelling reason. Feel free to say "nah you are full of hot air" but please tell me why. I know someone mentioned the svn:externals support. Now, that is a MAJOR feature that might even get some money from concerned Drupal shops (hey, I can dream, can't I?) because it makes their life much easier. http://weierophinney.net/matthew/archives/132-svnexternals.html Derek complained about SVN naive tags. I said that a solution for immutable tags is already readily available: http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/svnperms.conf.examp... says tags/[^/]+/ = *(add) and there we are. I can ask around for other solutions.
Sure. The usual configuration is that SVN is provided by an Apache module (mod_dav and mod_dav_svn) usually over HTTPS so that passwords are not sniffable and mod_authz_svn provides access control. The documentation for this is http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html .
We could probably even make it authenticate against the users table from drupal.org. I remember that there were issues in the past with CVS passwords not matching... (I might be wrong about that though).
Yeah, this is a minor pain in the ass (my ass, to be precise, since I don't think anyone else has ever fielded one of the cvs_rename issues). But, I've been documenting the process in various issues and hopefully others could pick up some of this (relatively small, in the scheme of things) support load.
There are few requests because most people don't know that it's possible to rename files in CVS via a hack. And even if they do know, they are reluctant because it takes time and is not something they can do immediately themselves.
cvs tag -b DRUPAL-7--1
we can say
svn copy /contributions/HEAD/modules/foo /contributions/DRUPAL-7--1/ modules/foo/
It's SO much easier to explain this because this is what you have on your hard drive. The cvs tag/branch essentially means virtual directories meaning an abstraction layer which people need to comprehend. Here you have files directories and nothing virtual. (Let's not fight now the actual paths we can discuss how to lay out our repo).
The concept of tags as CVS implements it is indeed not easy to grasp, especially if you use a GUI client. I remember that I had a hard time tagging and branching things (documentation was not as good as it is nowadays back then, admittedly). It's much easier if you see that you have different directories with the same directory layout underneath them. I agree that SVN's notion of tags is somewhat different from CVS' approach (which is not necessarily bad, it's just more difficult to understand, imho), but it's certainly not bad. Merging things between branches or copying files from one branch to another or just plain diffing of two branches/tags are more straightforward in SVN because you *see* the directory layout on your hard disk instead of imagining all the different "shadow versions" of the file in your head. Konstantin
On Jul 31, 2008, at 10:46 AM, Derek Wright wrote:
4. Much, much more intuitive commands.
This doesn't matter if people already know the CVS commands. If they don't, we've got handouts, handbooks, screencasts, DrupalCon talks, off-site writeups, and more, explaining what they need to know... And, as Earl pointed out, the most important commands for tagging and branching are arguably much less intuitive, and those are the ones people seem to have the most trouble with.
For whatever my experience is worth... I used CVS quite a bit between 1998 and 2001, and then not at all until 2003. In 2001 I was still R'ingTFM to do what should have been simple stuff. I then had to go back in 2003 and again in 2005 to work on old projects and had to relearn CVS each time, and it was like learning it for the first time. Moving from a CVS skillset (such as it was... clearly I never had a great grasp on CVS) to an SVN skillset has been easy. I still look up commands from time to time, but most of the time I just use it and get on with my work. Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells. So I'm ashamed to admit this, but I was granted my CVS account here four months ago and I haven't done anything at all. Nothing. Realistically, I may never actually contribute to Drupal in any meaningful manner, because every time I sit down to do some work it becomes a choice between spending a day fixing bugs in code locally (which benefits me and no one else) and spending a day (or a week) dealing with relearning a version control system (which benefits no one at all). Day after day that means that my local codebase is becoming better and I'm not helping the community at all. All this means that I'm just a lazy doofus whose potential for contribution is probably worthless anyhow, but the work is getting done. I have a client paying me to do this work and another full-time developer at my disposal. Ultimately the life or death of any project where people are contributing their time centers around whether those people see benefit. Relearning CVS is something that benefits me not at all. (Well, that's not true. If I relearn and reinstall CVS I'd get the benefit of developers not junior to me reviewing my code). Seriously. If I put "knows CVS" on my résumé it's not going to get me any new projects. At best it might get me Learning skills is a career move, and asking developers to learn CVS is asking them to make a dead-end career move. Hey, here's a skill I'll only use once. Yay. Again, I understand that I haven't made any arguments about the technical merits of either CVS or SVN. But I'm neither lazy nor stubborn. I have a finite number of hours in the day and have to make choices about where I invest my time. Learning swingdancing is fun. Improving my SQL skills is profitable. Getting back up to speed with CVS is neither fun nor profitable. It's just punishment for wanting to help with the Drupal project. Having forced you to read this whingeing, I'll write a note to myself to at least get as far as checking out some code after I get home tonight. That is, assuming nothing more important and pleasurable, like washing the dishes or scrubbing my toilet, needs to be done. Steve
Steve Scotten wrote:
Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells.
You only need three commands: cvs checkout cvs commit cvs tag You'll need pretty much the same commands with an svn system as well. If this is difficult it is only because you're making it so.
Earl Miles wrote:
Steve Scotten wrote:
Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells.
You only need three commands:
cvs checkout cvs commit cvs tag
I'm wrong. It's a couple more: cvs up cvs diff cvs log is handy but not really needed.
On Aug 5, 2008, at 11:33 AM, Earl Miles wrote:
Steve Scotten wrote:
Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells.
You only need three commands:
cvs checkout cvs commit cvs tag
You'll need pretty much the same commands with an svn system as well. If this is difficult it is only because you're making it so.
Well, no, I also have to read up on creating the config files, define environment variables and anything else I need to do to get the CVS client to speak to another CVS server, since cvs --help checkout Usage: cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir] [-j rev1] [-j rev2] [-k kopt] modules... doesn't mention servernames or addresses anywhere. I don't remember what CVSROOT specifies and I think that's *probably* important information to know. Call me silly. That's assuming that the version I have (1.12.13) is compatible with the version we're using around here. It's dated 2005, so I'm guessing the odds are about 60/40 in favor. I'm not saying any of this is insurmountable. I've learned CVS three times already, I'm sure I can relearn it and it probably won't get me all confused with my SVN commands. I'm not *quite* that braindead. But it's still like interviewing for a job and finding out that I'd be required to use edlin to write my code. Yeah, it can be done, and edlin uses a small set of easy to remember commands, right? I'd still have to be pretty desperate to take such a job. (it was bad enough working for a place where vi was the only permitted development tool). It's not about me and I'm not pretending that this is a dealbreaker or should be the only consideration. It's just two facts to consider out of many: A CVS user can pick up SVN a lot more easily than an SVN user can pick up CVS, and SVN is the more useful skillset in the job market nowadays. If these are truly irrelevant, accept my apologies for piping up. Steve
On Tue, 2008-08-05 at 13:10 -0700, Steve Scotten wrote:
On Aug 5, 2008, at 11:33 AM, Earl Miles wrote:
Steve Scotten wrote:
Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells.
You only need three commands:
cvs checkout cvs commit cvs tag
You'll need pretty much the same commands with an svn system as well. If this is difficult it is only because you're making it so.
Well, no, I also have to read up on creating the config files, define environment variables and anything else I need to do to get the CVS client to speak to another CVS server, since
cvs --help checkout Usage: cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir] [-j rev1] [-j rev2] [-k kopt] modules...
doesn't mention servernames or addresses anywhere. I don't remember what CVSROOT specifies and I think that's *probably* important information to know. Call me silly.
That's assuming that the version I have (1.12.13) is compatible with the version we're using around here. It's dated 2005, so I'm guessing the odds are about 60/40 in favor.
I'm not saying any of this is insurmountable. I've learned CVS three times already, I'm sure I can relearn it and it probably won't get me all confused with my SVN commands. I'm not *quite* that braindead. But it's still like interviewing for a job and finding out that I'd be required to use edlin to write my code. Yeah, it can be done, and edlin uses a small set of easy to remember commands, right? I'd still have to be pretty desperate to take such a job. (it was bad enough working for a place where vi was the only permitted development tool).
It's not about me and I'm not pretending that this is a dealbreaker or should be the only consideration. It's just two facts to consider out of many: A CVS user can pick up SVN a lot more easily than an SVN user can pick up CVS, and SVN is the more useful skillset in the job market nowadays. If these are truly irrelevant, accept my apologies for piping up.
Steve
Just speaking for myself here, but I do think this line of discussion is fairly irrelevant, although maybe not for the first reason you'd think of. The original thread of this conversation focused on some of the technical pros/cons of the various version control systems that are out there, and my hope is that we all learned something from that interchange (I know I sure did). You've started branching towards the utility of a particular skillset in the marketplace, Steve, and in my mind, that's a relevant issue to consider - just not right now. There's a moderately clear path forward here, and it really starts with getting project* and vcs api where they need to be. Personally, I feel that these non-technical pro/con discussions are irrelevant until we've got the technical capability to make changing vcs a reality - and consequently, I tend to look on such discussions as time that could've been better spent coding :) Sam
On Aug 5, 2008, at 1:29 PM, Sam Boyer wrote:
irrelevant until we've got the technical capability to make changing vcs a reality - and consequently, I tend to look on such discussions as time that could've been better spent coding :)
That's fair, though if keeping things as they are is the most desirable course, why bother even pursuing the capability to change? If the advantages of SVN or some other system are not real advantages (or at least not for our purposes) then shouldn't we avoid developing the capability to change vcs? Hahah. OK, I caught myself saying "we" on a whole aspect that I don't even want to help with. Forgive me. I'll stop being a buttinsky and go back to the stuff I've actually volunteered to do. =^) Thanks, Steve
Steve Scotten wrote:
On Aug 5, 2008, at 11:33 AM, Earl Miles wrote:
Steve Scotten wrote:
Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells.
You only need three commands:
cvs checkout cvs commit cvs tag
You'll need pretty much the same commands with an svn system as well. If this is difficult it is only because you're making it so.
Well, no, I also have to read up on creating the config files, define environment variables and anything else I need to do to get the CVS client to speak to another CVS server, since
I've never touched a cvs config file, nor defined an environment variable for it.
cvs --help checkout Usage: cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir] [-j rev1] [-j rev2] [-k kopt] modules...
Luckily, drupal.org knows this command: Available as a page beneath http://drupal.org/handbooks/repos (which in turn is beneath handbooks/cvs): http://drupal.org/node/321 I wouldn't expect cvs to know where our repositories are anyway, so you have to get information from drupal.org on where to check out anyway. Conveniently the exact command you need is in the same place...
That's assuming that the version I have (1.12.13) is compatible with the version we're using around here. It's dated 2005, so I'm guessing the odds are about 60/40 in favor.
If version compatibility were an issue, people would complain. A lot.
It's not about me and I'm not pretending that this is a dealbreaker or should be the only consideration. It's just two facts to consider out of many: A CVS user can pick up SVN a lot more easily than an SVN user can pick up CVS, and SVN is the more useful skillset in the job market nowadays. If these are truly irrelevant, accept my apologies for piping up.
If you say so, but eh. If we could snap our fingers and switch to svn, we would. I promise you, it's a lot easier for you to figure out the CVS commands than it is for all of drupal.org to change all of our tools and code to use svn instead of cvs. But that's okay; there's a lot more to maintaining a contribution than just using CVS, and if CVS is an impediment for you, I expect the other stuff will be worse anyway.
Steve Scotten said:
Bottom line: I have no desire to become any sort of expert or even semiexpert in version control. I want version control to be a tool subservient to my needs rather than a black hole sucking up my time, attention, and overtaxed brain cells.
I am pretty certain that I will get no argument from Derek as to my not being even a semi-expert on CVS. But I use it and with little trouble. In the time you spent writing your email, you could have learned almost everything you need to maintain a single branch of a module. Granted, maintaining more than one branch will take you another 10 minutes to figure out. Derek wrote a reply to me that clarified it all much better than anything else: http://drupal.org/node/197826#comment-649422. I suggest a quick read - well, okay a careful read. Nancy E. Wichmann, PMP No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.12/1590 - Release Date: 8/4/2008 8:09 AM
On Thu, 2008-07-31 at 12:40 -0400, Angela Byron wrote:
Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adrian Rossouw schrieb:
On 31 Jul 2008, at 12:42 PM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better. Wow. that's quite a turn around =)
I also like SVN over the others in that it removes complexity instead of adds more.
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving.
SVN provides a few advantages that make it compelling: 1. Security. pserver authentication is horribly, horribly insecure. 2. The ability to rename and move files, retaining version history, without having to post a support request to the repository maintainers. 3. The ability to remove directories without having to post a support request to the repository maintainers. 4. Much, much more intuitive commands. Compare:
cvs tag -d DRUPAL-5--1-0 svn remove tags/DRUPAL-5--1-0
cvs up -dPC filename.inc svn revert filename.inc
5. Spend some time browsing through http://drupal.org/project/issues?projects=107028&components=CVS, and you see an awful lot of requests there that wouldn't be there if we were using SVN. For example, it's amazing how often "I need a tag deleted" comes up, because people can't figure out the command to do it. A lot of others are "D'oh. I accidentally committed something somewhere I didn't mean to, and now I want to (re)move it. I can't. Help?" So the support burden on our repository admins (after the initial bout of total confusion, of course ;)) would be remarkably less. 6. I don't know a lot about SVK, but if SVK can be combined with SVN to provide the advantages of DRCS for advanced users, without reducing our pool of contributors to like 5%, then cool. ;) 7. The SVN community is completely awesome and helpful. I've asked some pretty 'n00b' questions in #svn and always been treated not only with respect, but with a 20-minute answer to my problem.
However, the one thing about SVN that terrifies the living Hell out of me is the fact that there is no such thing as a tag. There are only branches, and branches that you don't commit things to (wink wink) are "tags". Judging by the number of people who screw this up now, I can't imagine the utter chaos we'd have if the "stable" 5.x-1.0 release of a module could change on a whim. However, it might be that we could do some funky pre-commit scripts or something to enforce the CVS idea of a tag. If we go down this route, I'm sure the ever-awesome SVN community could help us figure it out. :)
-Angie
Oh my oh my. Please please, folks, have a look at: http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.branchmerge and possibly the next section, http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.reposadmin svn doesn't have native, hard-coded branching and tagging the way that cvs does. Instead, we have a lot more flexibility and are able to define workflows for how our releases work. BTW, that reminds me - Derek (or anyone who knows), how does the current release packaging system work? Does it iterate over the whole repo and check for changes, or does CVS notify it about the creation of new release tags so that it can target its efforts more efficiently? Sorry if there's a page explaining that somewhere... cheers s
On Jul 31, 2008, at 11:16 AM, Sam Boyer wrote:
BTW, that reminds me - Derek (or anyone who knows), how does the current release packaging system work? Does it iterate over the whole repo and check for changes, or does CVS notify it about the creation of new release tags so that it can target its efforts more efficiently? Sorry if there's a page explaining that somewhere...
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project/ release/package-release-nodes.php?view=markup There's a page explaining parts of it, but that's on infrastructure.drupal.org, and that means the vast majority of the people reading this message won't have permission to view it. So, I just wrote it up here: http://drupal.org/node/289662 Enjoy, -Derek (dww)
Quoting Gerhard Killesreiter <gerhard@killesreiter.de>:
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving.
That is certainly the opinion I hold for projects I maintain elsewhere. If it is already in CVS there is no need to switch to SVN. The hardship people tend to have with CVS is understanding the meaning of branch and release tags. However, Drupal has well defined meanings for those and the release tools and documentation handle them well. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
One case study to look at, both to see how painful RCS migration can be as well as showing that it can be done, would be freebsd's ongoing migration of their huge and ancient repository from CVS to Subversion. For the time being, the CVS repository is still in place along with all the infrastructure tied to it; commits are made to SVN, constantly mirrored to CVS, and releases are made from CVS. Some notes about it here: http://people.freebsd.org/~peter/svn_notes.txt http://lists.freebsd.org/pipermail/freebsd-current/2008-June/086023.html --mark On Thu, Jul 31, 2008 at 10:10 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Gerhard Killesreiter <gerhard@killesreiter.de>:
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving.
That is certainly the opinion I hold for projects I maintain elsewhere. If it is already in CVS there is no need to switch to SVN. The hardship people tend to have with CVS is understanding the meaning of branch and release tags. However, Drupal has well defined meanings for those and the release tools and documentation handle them well.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
The hardship people tend to have with CVS is understanding the meaning of branch and release tags. However, Drupal has well defined meanings for those and the release tools and documentation handle them well.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
For me, the problem isn't understanding the concept of a branches and tags, but getting CVS to tell me the reality of those branches and tags. Maybe I just haven't learned how to use the tool properly, but I am constantly worried that I've crossed branches and tagged the wrong files. I know what I should do, but I don't know if that's what I did. I feel like I've learned the concepts of VCS much easier with Bazaar than I ever would have with CVS. That's mostly because I actually felt comfortable using it. --Lyle
On Jul 31, 2008, at 11:27 AM, Lyle Mantooth wrote:
I know what I should do, but I don't know if that's what I did.
Then get in the habit of running "cvs status" a lot. ;) As I wrote in my handout about release management[1], before every cvs commit, you should run: cvs diff # is this the patch and only the patch i mean to be committing? cvs status # is this the branch i mean to be committing to? ditto, before every cvs tag, you should run "cvs status"... cheers, -Derek (dww) [1] http://drupal.org/files/maintain-release-handout.pdf
Hi, I have a couple of projects running in Darcs and the repository does not scale at all! I am talking about small projects and when I get to around 500 commits the system really starts getting soooooo sloooooow. If it needs to be a centralize RCS, the I hope to SVN mainly because the git connectivity is so good, and it really works like just another git repository. How ever because SVN doesn't know how to tag or branch I don't think that the upstream use of branches will work that well. Gordon. On 31/07/2008, at 8:42 PM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better.
And back to Drupal contrib, at least with a central repo you can have some central control trying to keep order but with a DRCS all bets are off. Check contrib CVS root for all the crap our CVS challenged contributors add there and think what would ensue with a DRCS.
It's highly debatable that the most serious of our problems, namely understanding RCS would be solved by any DRCS. You sure want to explain multiple heads for one or patch algebra for another? How does 140+ commands sound (and then some has one or two superb powerful switches...) This is a terrible mess.
Now, with SVN we wll need a script to stop tagged things from being changed because they are not immutable as they were in CVS -- but this is readily available and this is the only problem I am aware of. SVN concepts are mapping much better to reality -- one dir per branch/tag. Makes it (much) easier to understand. You already keep a separate directory for your branches so that's how the repository looks like, easy! Thus it _will_ solve some problems -- another problem with DRCS that it does nto solve the problems we have :) SVN tools are available. SVN is mature and documentation is plentiful. svn 1.5 added merge tracking for (much) better team work.
Feature foo and bar might be unavailable for SVN but I can not care , we need something that we, we all of the Drupal community can use.
Once the reboot of my life is complete (read: September) I will rejoin the moving effort and help.
!DSPAM:1000,4891974841741299430736!
Gordon Heydon wrote:
If it needs to be a centralize RCS, the I hope to SVN mainly because the git connectivity is so good, and it really works like just another git repository. How ever because SVN doesn't know how to tag or branch I don't think that the upstream use of branches will work that well.
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
On Thu, 2008-07-31 at 09:01 -0700, Earl Miles wrote:
Gordon Heydon wrote:
If it needs to be a centralize RCS, the I hope to SVN mainly because the git connectivity is so good, and it really works like just another git repository. How ever because SVN doesn't know how to tag or branch I don't think that the upstream use of branches will work that well.
Doesn't know how to tag or branch? Sorry, that's just not true.
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
I've heard svn's branching system called a lot of things, but in comparison to cvs, 'naive' is a new one on me. One of the points svn bills itself on is "easy branching and tagging." And it's true. Avoiding project spaghetti (aka, the more-or-less constant state of the cvs/drupal-contrib directory) and managing release tags becomes a question of a) using the svn hook system and b) how we organize the contrib repo(s) in the first place. Sam
Hi, On 01/08/2008, at 2:01 AM, Earl Miles wrote:
Gordon Heydon wrote:
If it needs to be a centralize RCS, the I hope to SVN mainly because the git connectivity is so good, and it really works like just another git repository. How ever because SVN doesn't know how to tag or branch I don't think that the upstream use of branches will work that well.
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
Yes this is my major concern with SVN, the total lack of tagging and branching support. Gordon.
On Fri, 2008-08-01 at 09:00 +1000, Gordon Heydon wrote:
Hi, On 01/08/2008, at 2:01 AM, Earl Miles wrote:
Gordon Heydon wrote:
If it needs to be a centralize RCS, the I hope to SVN mainly because the git connectivity is so good, and it really works like just another git repository. How ever because SVN doesn't know how to tag or branch I don't think that the upstream use of branches will work that well.
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
Yes this is my major concern with SVN, the total lack of tagging and branching support.
Gordon.
This just isn't accurate. Several posts in this discussion - not even all of them being mine - have indirectly or directly explained that svn does have branching/tagging. Sam
Hi, On 01/08/2008, at 9:32 AM, Sam Boyer wrote:
On Fri, 2008-08-01 at 09:00 +1000, Gordon Heydon wrote:
Hi, On 01/08/2008, at 2:01 AM, Earl Miles wrote:
Gordon Heydon wrote:
If it needs to be a centralize RCS, the I hope to SVN mainly because the git connectivity is so good, and it really works like just another git repository. How ever because SVN doesn't know how to tag or branch I don't think that the upstream use of branches will work that well.
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
Yes this is my major concern with SVN, the total lack of tagging and branching support.
Gordon.
This just isn't accurate. Several posts in this discussion - not even all of them being mine - have indirectly or directly explained that svn does have branching/tagging.
Yes it does have very basic tagging/branching but when you compare this is git, dvcs, etc and even cvs they are head and shoulders above SVN tagging/branching Gordon.
On Thu, Jul 31, 2008 at 9:36 PM, Gordon Heydon <gordon@heydon.com.au> wrote: Why "head and shoulders above SVN tagging/branching"? Could you or others making these kinds of assertions possibly justify them? They are stated as if they were "self-evident truths". I used SCCS for over a decade on various flavors of Unix. CVS was then the new kid on the block, and I used that for a decade and a half. Then, SVN, with its very functional tagging and branching system, brilliantly optimized as the economical copying of pointers, have simplified everything and given much better support for binary files, precision directory permissions on the group and user level, a system rich in pre-process and post-process hooks, an API usable by various languages, WebDav (read-only) for basic browsing... The whole idea of this thread is to discuss how Drupal can be firmly rooted in the tools and workflows that real world developers actually use on an everyday basis, and for good reason; so as to encourage, as webchick wrote, best practices, and, making Drupal convenient, adoptable... Larry Garfield has explained how for a small core of users, a distributed RCS (such as git, mercurial, etc.) could be superior, but SVN is the most mainstream, is what people actually use. git is also creating quite a following among single developers (those not married to a group) who love the "stand alone", local versioning option while retaining the option to "push" (commit) to a server... You go out and contract repository hosting, as I do, for $7 / month I get unlimited repositories with a TRAC instance for each... cool. Most of these are offering git also. With GUI's such as TortoiseSVN and RapidSVN, etc.... it just seems the most attractive and useful way to go. The only argument against that might make some sense is what Earl Miles said about it probably being a lot of hard work perhaps better spent on other worthy core causes. Yet there is something to be said for using tools people use and for good reason. Victor Kane http://awebfactory.com.ar
Yes this is my major concern with SVN, the total lack of tagging and branching support.
Gordon.
This just isn't accurate. Several posts in this discussion - not even all of them being mine - have indirectly or directly explained that svn does have branching/tagging.
Yes it does have very basic tagging/branching but when you compare this is git, dvcs, etc and even cvs they are head and shoulders above SVN tagging/branching
Gordon.
On Thursday 31 July 2008 6:32:25 pm Sam Boyer wrote:
Yes this is my major concern with SVN, the total lack of tagging and branching support.
Gordon.
This just isn't accurate. Several posts in this discussion - not even all of them being mine - have indirectly or directly explained that svn does have branching/tagging.
Sam
I think this is a terminology difference, frankly. In CVS, branching and tagging is an explicit, discrete operation named tag (or tag -b, which is just dumb). You create a tag/branch by saying "Hey, CVS, make a branch from here and call it X". CVS then does some magic copying and shuffling behind the scenes. In SVN, there is no explicit concept of branching and tagging. The way SVN works internally, you can copy files within the repository dirt cheap. It creates essentially the svn equivalent of a hard link in the file system. (It's not implemented that way, but it's conceptually similar.) Because copying is always an O(1) operation that takes virtually no extra disk space, you "branch" by copying one working copy to a new location within the repository. You can then start committing to that new location and svn tracks the changes internally as needed. The only difference between a branch and a tag is a convention to not commit to a tag; CVS would enforce that by its very nature, whereas in CVS there is no inherent difference between a branch, a tag, and just copying files around. Whether SVN's mechanism is more natural and obvious (you can see all your branches at once, very useful when different people use different branching structures for their modules) or more geeky-obscure (I want to "branch" so why do I use the copy command? What is this, the "Start" button to Shutdown?) is a matter of opinion; I've seen both expressed, both in this thread and elsewhere. -- Larry Garfield larry@garfieldtech.com
Larry Garfield wrote:
On Thursday 31 July 2008 6:32:25 pm Sam Boyer wrote:
Yes this is my major concern with SVN, the total lack of tagging and branching support.
Gordon. This just isn't accurate. Several posts in this discussion - not even all of them being mine - have indirectly or directly explained that svn does have branching/tagging.
Sam <snip> The only difference between a branch and a tag is a convention to not commit to a tag; CVS would enforce that by its very nature, whereas in CVS there is no inherent difference between a branch, a tag, and just copying files around.
This is true of SVN's default behaviour. I've been schooled this evening by Sam that SVN pre-commit hooks can make SVN emulate CVS's definition of a tag perfectly. So I'm no longer concerned about this issue. -Angie
On Thu, Jul 31, 2008 at 11:01 AM, Earl Miles <merlin@logrus.com> wrote:
It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
As some of you know, about a year ago I wrote a port of cvslog.module that uses Subversion instead of CVS, but otherwise is pretty much identical. In the process I had to modify the xcvs scripts to function properly with Subversion. I've been using this module on a site I run, and the conventions used on the site are pretty similar to what's used on d.o, especially relating to the tag and branch naming conventions. Basically, the script requires that tags be in /project_name/tags and branches be in /project_name/branches. I can't say the scripts are foolproof, as there are many fewer users on my site, but it's worked well so far. The downside is that this is not done using the Versioncontrol API, and so probably not something that we'd want to use directly on d.o. But I am pretty confident that we could use SVN and keep pretty similar conventions. Adam
On Jul 31, 2008, at 3:42 AM, Karoly Negyesi wrote:
If we move, we move to SVN.
On Jul 31, 2008, at 4:04 AM, Gerhard Killesreiter wrote:
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving.
On Jul 31, 2008, at 9:01 AM, Earl Miles wrote:
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
In that case, we're exactly where we've been for at least the last 2 years. This comes as no surprise at all, and why I've never had much of a sense of urgency about this situation. To summarize: - DVCS is relatively new, immature, and very complicated. The basic level of understanding among Drupal developers of even simple VCS and release management 101 is so low that a DVCS would produce vastly more problems than it would solve. At least for the foreseeable future, DVCS is out of reach for the overall Drupal developer community. Maybe in N years when the tools are more mature, the documentation is better, and more people have gained knowledge of DVCS concepts in other areas of their technical lives, we can reopen this part of the thread. - The only viable traditional VCS alternative to CVS is SVN, which only has minor feature improvements, and has a serious conceptual drawback with its naive tagging semantics. Therefore, a switch away from CVS will require massive effort for little or no gain. Shall I update Angie's FAQ to summarize this state of affairs? Can we put this thread to rest for another 2 years? Cheers, -Derek (dww) p.s. Sam, please don't let that stop you from taking over versioncontrol_api. That'd still be a good thing for project*, even if d.o isn't using SVN or git. ;)
On Thu, 2008-07-31 at 10:19 -0700, Derek Wright wrote:
On Jul 31, 2008, at 3:42 AM, Karoly Negyesi wrote:
If we move, we move to SVN.
On Jul 31, 2008, at 4:04 AM, Gerhard Killesreiter wrote:
Well, then we just can stay with CVS. IMO SVN's features aren't that vastly superior to spend much effort on moving.
On Jul 31, 2008, at 9:01 AM, Earl Miles wrote:
This is my concern with SVN. Its idea of tagging and branching is naive and I find it confusing and also intensive when I end up checking out all the tags unintentionally. It seems like it would be difficult to translate our current tagging system to SVN and I am concerned that the amount of work to do so would be wasted effort. IMO, we have a lot more important problems to solve than this.
In that case...
Ahhh! It's not the case! I've been trying to put out these fires as fast as I can, but I can only type so fast :) I've personally done cvs to svn migrations before, and they do take considerable care and effort, but they're not impossible. Plus, as I've said in a few emails already, the tagging/branching system _is_ mature (quite a bit more so than CVS, in fact), it's just more flexible and we'd need to tailor it. Not like we ever tell anybody that about drupal or anything... :P Also, as a specific response to Earl - inadvertently checking out everything from svn is no easier or harder than cvs. It's just different. It's the default trunk/ branches/ tags/ that tends to cause inadvertent enormous checkouts like that, and folks accustomed to cvs are more likely to do it. Fortunately, since that repo layout isn't hard-coded into svn, we could take steps to reduce that confusion by making the layout more familiar to cvs users.
we're exactly where we've been for at least the last 2 years. This comes as no surprise at all, and why I've never had much of a sense of urgency about this situation. To summarize:
- DVCS is relatively new, immature, and very complicated. The basic level of understanding among Drupal developers of even simple VCS and release management 101 is so low that a DVCS would produce vastly more problems than it would solve. At least for the foreseeable future, DVCS is out of reach for the overall Drupal developer community. Maybe in N years when the tools are more mature, the documentation is better, and more people have gained knowledge of DVCS concepts in other areas of their technical lives, we can reopen this part of the thread.
- The only viable traditional VCS alternative to CVS is SVN, which only has minor feature improvements, and has a serious conceptual drawback with its naive tagging semantics.
Therefore, a switch away from CVS will require massive effort for little or no gain.
Shall I update Angie's FAQ to summarize this state of affairs? Can we put this thread to rest for another 2 years?
Cheers, -Derek (dww)
p.s. Sam, please don't let that stop you from taking over versioncontrol_api. That'd still be a good thing for project*, even if d.o isn't using SVN or git. ;)
No worries :) As I said in the caveat of my initial response here, I'm just providing information, not advocating. Really, even if it doesn't sound like it at times :P. I've already taken over vcs api, and will be doing what's needed there regardless of how all these decisions play out. cheers, s
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better. And back to Drupal contrib, at least with a central repo you can have some central control trying to keep order but with a DRCS all bets are off. Check contrib CVS root for all the crap our CVS challenged contributors add there and think what would ensue with a DRCS. It's highly debatable that the most serious of our problems, namely understanding RCS would be solved by any DRCS. You sure want to explain multiple heads for one or patch algebra for another? How does 140+ commands sound (and then some has one or two superb powerful switches...) This is a terrible mess. Now, with SVN we wll need a script to stop tagged things from being changed because they are not immutable as they were in CVS -- but this is readily available and this is the only problem I am aware of. SVN concepts are mapping much better to reality -- one dir per branch/tag. Makes it (much) easier to understand. You already keep a separate directory for your branches so that's how the repository looks like, easy! Thus it _will_ solve some problems -- another problem with DRCS that it does nto solve the problems we have :) SVN tools are available. SVN is mature and documentation is plentiful. svn 1.5 added merge tracking for (much) better team work. Feature foo and bar might be unavailable for SVN but I can not care , we need something that we, we all of the Drupal community can use. Once the reboot of my life is complete (read: September) I will rejoin the moving effort and help.
(This post is directed as much for developers out there, and companies with their own process than it is at d.o) I've recently been through a similar process with the company I'm with now, and come to the same conclusion regarding SVN. While I prefer to do my own personal projects in other systems, SVN is the lowest common denominator of VCS that I could find. I am the first full time developer at my company, and the other employees must have a GUI or they can't use VCS. We are currently stuck in a mix of another DVCS that is not working well, as there is not enough documentation, and neither I nor the consultant who previously set this up for them are experienced in it, rather the consultant wanted to be cutting edge and move to a distributed system. The other major complaint I have at this point, is that moving to a specific DVCS has actually limited workflow options. Previous companies/clients which used SVN actually had more options since almost every major DVCS (hg/git/bzr) has an SVN plugin to allow directly working with a SVN repository. This allows each developer to use the methodologies/workflow that best suits them, for their development. -Mike On Jul 31, 2008, at 3:44 AM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better.
And back to Drupal contrib, at least with a central repo you can have some central control trying to keep order but with a DRCS all bets are off. Check contrib CVS root for all the crap our CVS challenged contributors add there and think what would ensue with a DRCS.
It's highly debatable that the most serious of our problems, namely understanding RCS would be solved by any DRCS. You sure want to explain multiple heads for one or patch algebra for another? How does 140+ commands sound (and then some has one or two superb powerful switches...) This is a terrible mess.
Now, with SVN we wll need a script to stop tagged things from being changed because they are not immutable as they were in CVS -- but this is readily available and this is the only problem I am aware of. SVN concepts are mapping much better to reality -- one dir per branch/tag. Makes it (much) easier to understand. You already keep a separate directory for your branches so that's how the repository looks like, easy! Thus it _will_ solve some problems -- another problem with DRCS that it does nto solve the problems we have :) SVN tools are available. SVN is mature and documentation is plentiful. svn 1.5 added merge tracking for (much) better team work.
Feature foo and bar might be unavailable for SVN but I can not care , we need something that we, we all of the Drupal community can use.
Once the reboot of my life is complete (read: September) I will rejoin the moving effort and help.
__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax
A distributed VCS would really only offer a benefit if it gets integrated into our development workflow. Were we to instead of having one single maintainer for all of Drupal (or a given version) have subsystem maintainers with partial commit access, the way the Linux kernel does, that would be much easier with a DVCS than with CVS or SVN. (It's probably something we should consider in the near future.) A DVCS could also potentially make major overhauls like FAPI, the theme system, or the new Database API easier to manage as we wouldn't need external svn repositories to coordinate that work. (That has been a sizable pain in the butt for the Database API rewrite.) All of those would require drastic changes to the Way We Work(tm). Unless we are going to make such a change to our development workflow, a DVCS doesn't offer much benefit. Several projects seem to have addressed that issue with, as others have noted, an SVN core repository with a git bridge. I believe PHP itself is planning to do so. That gives a "traditional" VCS for most people while allowing the 5% of users who would actually benefit from a DVCS to sorta use it, although not with all of its benefits. Were we to move off of CVS, at this point that would be my recommendation. Another advantage of svn over CVS that I don't think anyone has mentioned is that, as far as I am aware, it is much easier to do fancy external linking with SVN than CVS. If managed properly, that could be a boon for Drupal companies (like Palantir, where we have been discussing this exact problem) who want to tie their source management more tightly to Drupal's. Let's face it, checking out from CVS into an SVN repository is a hack, and Drupal abhors hacks. :-) --Larry Garfield On Thu, 31 Jul 2008 09:51:28 -0700, Michael Prasuhn <mike@mikeyp.net> wrote:
(This post is directed as much for developers out there, and companies with their own process than it is at d.o)
I've recently been through a similar process with the company I'm with now, and come to the same conclusion regarding SVN. While I prefer to do my own personal projects in other systems, SVN is the lowest common denominator of VCS that I could find. I am the first full time developer at my company, and the other employees must have a GUI or they can't use VCS. We are currently stuck in a mix of another DVCS that is not working well, as there is not enough documentation, and neither I nor the consultant who previously set this up for them are experienced in it, rather the consultant wanted to be cutting edge and move to a distributed system.
The other major complaint I have at this point, is that moving to a specific DVCS has actually limited workflow options. Previous companies/clients which used SVN actually had more options since almost every major DVCS (hg/git/bzr) has an SVN plugin to allow directly working with a SVN repository. This allows each developer to use the methodologies/workflow that best suits them, for their development.
-Mike
On Jul 31, 2008, at 3:44 AM, Karoly Negyesi wrote:
If we move, we move to SVN. My team, consisting of mostly pretty good coders tried a few distributed RCSes and given this experience I am now vehemently against any DRCS. The concepts are way too heavy and the utilities are not ready. Most of these systems are not that mature thus any docs from 1-2 years ago are worthless thus documentation is not much. When I was for a DRCS in 2005/2006 I was a naive greenhorn sorry for the ruckus I caused then, I now know better.
And back to Drupal contrib, at least with a central repo you can have some central control trying to keep order but with a DRCS all bets are off. Check contrib CVS root for all the crap our CVS challenged contributors add there and think what would ensue with a DRCS.
It's highly debatable that the most serious of our problems, namely understanding RCS would be solved by any DRCS. You sure want to explain multiple heads for one or patch algebra for another? How does 140+ commands sound (and then some has one or two superb powerful switches...) This is a terrible mess.
Now, with SVN we wll need a script to stop tagged things from being changed because they are not immutable as they were in CVS -- but this is readily available and this is the only problem I am aware of. SVN concepts are mapping much better to reality -- one dir per branch/tag. Makes it (much) easier to understand. You already keep a separate directory for your branches so that's how the repository looks like, easy! Thus it _will_ solve some problems -- another problem with DRCS that it does nto solve the problems we have :) SVN tools are available. SVN is mature and documentation is plentiful. svn 1.5 added merge tracking for (much) better team work.
Feature foo and bar might be unavailable for SVN but I can not care , we need something that we, we all of the Drupal community can use.
Once the reboot of my life is complete (read: September) I will rejoin the moving effort and help.
__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax
Angela Byron wrote:
Since we're all sick of answering this question every week, I've made an attempt at documenting this here:
If someone has some of the old threads laying around and could help flesh that page out (esp. with "here's where you jump in if you want to change this" stuff), that'd be lovely.
-Angie
Ok, I believe http://drupal.org/node/289117 now reflects most of what was covered in this thread: * Pros and cons of Subversion * Pros and cons of DVCS (needs work) * Note that SVN is likely the best choice. * Fleshed out "How you can help" * Changed the FAQ to "Why is Drupal still using CVS and how can I help change that?" to appease Moshe. :D I'm sure I'm missing stuff. Please help. The revisions tab is lonely. ;) -Angie
Before we once again leave this subject behinds there's just one more issue I'd like to see addressed - that of commitment. We have a clear desire by most of the community to move off of CVS, clear arguments as to why and where to move too and a pretty clear list of what actually needs to be done. But we're still in a position where those with the power to veto the decision to move altogether (Gerhard, Dries? who else?) appear to be saying somehting like: "No, I see no advantages, we're not going to do this." Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move? Without that I just don't see the community putting in the massive effort that's required. -- Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
BTW is it intentional that comments are disabled on that page??? -- Sean Burlington www.practicalweb.co.uk
Yes, it is. :-) Angie turned them off so that the handbook page doesn't turn into a discussion (which it has enormous potential to do). That is not what the handbook is for. If you see something that needs to be corrected on the page, you can file a documentation issue for correction (or of on the docs team, edit it). If you want to continue *discussion* about it then feel free to start a forum thread that points to it. - Addi On Aug 1, 2008, at 10:30 AM, Sean Burlington wrote:
Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
BTW
is it intentional that comments are disabled on that page???
--
Sean Burlington
www.practicalweb.co.uk
Sean Burlington wrote:
Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
BTW
is it intentional that comments are disabled on that page???
Yes. Absolutely, completely and utterly intentional. We do not need to re-hash this discussion in the handbooks. Let's get our ya-ya's out here and then document it there for posterity. If the reason you want to comment is to start organizing people around this topic, make a thread in the revision control group and we can link to it from this page. "If you'd like to help, there are efforts going on at <link>." If it's not, comment here instead. ;) -Angie
Angela Byron wrote:
Sean Burlington wrote:
Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
BTW
is it intentional that comments are disabled on that page???
Yes. Absolutely, completely and utterly intentional. We do not need to re-hash this discussion in the handbooks. Let's get our ya-ya's out here and then document it there for posterity.
sigh... Drupal seems like such a closed shop.. denying comment just adds to the impression Even if the discussion wasn't useful - why prevent it?! and without a response to Adrian's question I doubt anyone will put in the effort ... and this discussion will come up again. -- Sean Burlington www.practicalweb.co.uk
Sean Burlington wrote:
is it intentional that comments are disabled on that page???
Yes. Absolutely, completely and utterly intentional. We do not need to re-hash this discussion in the handbooks. Let's get our ya-ya's out here and then document it there for posterity.
sigh... Drupal seems like such a closed shop..
denying comment just adds to the impression
Even if the discussion wasn't useful - why prevent it?!
??? I'm not denying discussion. Discussion can happen here on the mailing list (as it has, very healthily so), in the issue tracking/revision control groups on groups.drupal.org (which is a great place for interested people to collaborate on fixing this), or in the Documentation issue queue (if you feel there are errors/omissions -- or just join the docs team and you can fix them yourself: http://drupal.org/contribute/documentation/join). The referenced node is a piece of *documentation*. Discussion does not belong within a piece of documentation, especially not THIS piece of documentation whose sole purpose is to aggregate all the various discussions that have happened over the years.
and without a response to Adrian's question I doubt anyone will put in the effort ... and this discussion will come up again.
Yes, that's probably true. I don't think this thread is done yet. :) -Angie
On Fri, 2008-08-01 at 16:57 +0100, Sean Burlington wrote:
Angela Byron wrote:
Sean Burlington wrote:
Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
BTW
is it intentional that comments are disabled on that page???
Yes. Absolutely, completely and utterly intentional. We do not need to re-hash this discussion in the handbooks. Let's get our ya-ya's out here and then document it there for posterity.
sigh... Drupal seems like such a closed shop..
denying comment just adds to the impression
Even if the discussion wasn't useful - why prevent it?!
and without a response to Adrian's question I doubt anyone will put in the effort ... and this discussion will come up again.
*Snip* On Thu, 2008-07-31 at 10:19 -0700, Derek Wright wrote: ...
p.s. Sam, please don't let that stop you from taking over versioncontrol_api. That'd still be a good thing for project*, even if d.o isn't using SVN or git. ;)
On Thu, 2008-07-31 at 13:34 -0500, Sam Boyer wrote: ...
No worries :) As I said in the caveat of my initial response here, I'm just providing information, not advocating. Really, even if it doesn't sound like it at times :P. I've already taken over vcs api, and will be doing what's needed there regardless of how all these decisions play out.
*/Snip* To the extent that working on version control API will contribute to moving in this direction, I'm committed. Honestly, my feeling is that Adrian's request puts Dries/Gerhard/whoever else in an untenable position. It's not that Angie hasn't done an 'empress of open-source awesomeness'-level job with the documentation on that page. It's that no one vested with the responsibility of managing something as important as d.o itself can be expected to solidly commit to implementing an amorphous path forward. We may have identified the right questions on that handbook page, but it doesn't mean they're going to produce tenable answers. Until we get to the point where either a) there's a specified proposal on the table (probably with funding attached to it) that details the process by which we would arrive at a new system, or b) enough of the necessary coding has already gotten done that it becomes possible to 'see' our way through to a concrete solution (which would then STILL need to be written up as a concrete proposal), I don't think it's fair to ask for any such commitment. I think that both a) and b) are feasible, and they're not mutually exclusive. I also tend to think that b) is considerably more likely to happen for a number of reasons (big surprise that it's the route I'm personally choosing to pursue), most importantly because it's the route that connects with work that currently needs doing - on project*, on vcs api, etc. And at the end of the day, that's really what I think about all this: if you want to see a better/smarter/niftier/whatever version control system in place for drupal, then participate in the drupal do-ocracy and help shape the tools we have into the tools they could/should be. Sam
Hi folks, As a version control junkie, I would be heavily in favor of this switch. For development shops, there is an added expense of training / fixing mistakes when people use CVS. I've been working in IT for 10yrs, so I know CVS fairly well (although it is foggy), but many of our developers are 22-25yrs old and have just heard of CVS the way I have heard of COBOL :). I can't say I will volunteer however to fix this across the drupal.org enterprise. What I can do if people are interested is help in securing funding for some people to do it. I don't know the drupal politics around this, but I believe this job may simply be too large and complex to pull off with a volunteer effort. I don't suppose this is something the Knight foundation would grant money too, but if not, would it be possible to pass the hat around to the various Drupal shops to raise money to support a couple people to take this on full time for a few weeks? Best, Jacob Singh Adrian Simmons wrote:
Before we once again leave this subject behinds there's just one more issue I'd like to see addressed - that of commitment. We have a clear desire by most of the community to move off of CVS, clear arguments as to why and where to move too and a pretty clear list of what actually needs to be done.
But we're still in a position where those with the power to veto the decision to move altogether (Gerhard, Dries? who else?) appear to be saying somehting like: "No, I see no advantages, we're not going to do this."
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
Without that I just don't see the community putting in the massive effort that's required.
On Aug 1, 2008, at 9:40 AM, Jacob Singh wrote:
What I can do if people are interested is help in securing funding for some people to do it. I don't know the drupal politics around this, but I believe this job may simply be too large and complex to pull off with a volunteer effort.
Hurray, the voice of reason! Indeed, part of why this hasn't already happened is that none of this is my full time job, I don't feel *that* strongly about it as a personal itch, and to date, the volunteer resources brought to the table have been insufficient to drive it home. Jakob made a heroic effort as a Summer of Code project last year, but that wasn't enough. We've done these sorts of fundraising efforts for various d.o infrastructure functionality in the past (e.g. the initial push for the release system itself, etc), and we'll do more of them in the future (big scale for the d.o redesign, small scale for things like a system for packaging up installation profiles with a copy of core and all the modules they require, and hopefully the D6 upgrade of d.o, etc). So yes, if you want to raise money to help fund the "remove dependencies on CVS and pave the way for XXX" effort, please do so. It will definitely help. Thanks, -Derek (dww)
On Aug 1, 2008, at 6:26 AM, Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
Once upon a time, in a post someone with time and motivation could surely find, Dries wrote something to the effect of: "I'd be happy to switch to something other than CVS _if all the dependencies on CVS are safely removed and addressed_". (approximate quote from memory). - The #1 dependency on CVS is project_release.module. - The #2 dependency on CVS is all the CVS account creation stuff. - The #3 dependency on CVS are the CVS commit log viewing pages, links on project nodes, etc. - The best way to fix all of that is VersionControl API. - There are pages dedicated to what needs to happen to get us closer, already linked from Angie's wonderful document. If all that work is done, d.o is running VersionControl API with the CVS backend, the SVN backend is demonstrated to be stable and working on project.drupal.org, we've got the packaging script ported and working, we've got the CVS -> SVN import documented and working, we've got all the SVN access control worked out (per project like we have now, preventing commits to tags, etc, etc), we've got something like svn.drupal.org setup care of the OSUOSL, and we've got a team of documentation folks lined up to go nuts, I can pretty safely guarantee that Dries will say "Yay, go for it!". That still doesn't answer the question of how the choice of SVN vs. XXX will ultimately be decided, nor if decree from Dries is good enough for the switch. The lack of a clear process for making decisions like this continues to haunt us. By default, a decree from Dries (if he's willing to make it) carries the day. If not, I guess decree from Dries on how to decide will be necessary. Meanwhile, it can't possibly hurt to at least move towards project* + versioncontrol_cvs as a first (monster) step down this path. The other stuff will be pretty easy (relatively speaking) once that's done. Hurray to Sam for volunteering to help. But I can assure you that more resources will be needed to finish the job. Cheers, -Derek (dww)
On Fri, 2008-08-01 at 11:18 -0700, Derek Wright wrote:
On Aug 1, 2008, at 6:26 AM, Adrian Simmons wrote:
Can we have a commitment that *if* everything needing to be done that Angie kindly listed on http://drupal.org/node/289117 and links therefrom *gets done* we *will* move?
Once upon a time, in a post someone with time and motivation could surely find, Dries wrote something to the effect of:
"I'd be happy to switch to something other than CVS _if all the dependencies on CVS are safely removed and addressed_".
(approximate quote from memory).
- The #1 dependency on CVS is project_release.module. - The #2 dependency on CVS is all the CVS account creation stuff. - The #3 dependency on CVS are the CVS commit log viewing pages, links on project nodes, etc. - The best way to fix all of that is VersionControl API. - There are pages dedicated to what needs to happen to get us closer, already linked from Angie's wonderful document.
If all that work is done, d.o is running VersionControl API with the CVS backend, the SVN backend is demonstrated to be stable and working on project.drupal.org, we've got the packaging script ported and working, we've got the CVS -> SVN import documented and working, we've got all the SVN access control worked out (per project like we have now, preventing commits to tags, etc, etc), we've got something like svn.drupal.org setup care of the OSUOSL, and we've got a team of documentation folks lined up to go nuts, I can pretty safely guarantee that Dries will say "Yay, go for it!".
That still doesn't answer the question of how the choice of SVN vs. XXX will ultimately be decided, nor if decree from Dries is good enough for the switch. The lack of a clear process for making decisions like this continues to haunt us. By default, a decree from Dries (if he's willing to make it) carries the day. If not, I guess decree from Dries on how to decide will be necessary.
Meanwhile, it can't possibly hurt to at least move towards project* + versioncontrol_cvs as a first (monster) step down this path. The other stuff will be pretty easy (relatively speaking) once that's done. Hurray to Sam for volunteering to help. But I can assure you that more resources will be needed to finish the job.
Indeed there will. Help is VERY welcome :) s
Cheers, -Derek (dww)
Derek Wright wrote:
Meanwhile, it can't possibly hurt to at least move towards project* + versioncontrol_cvs as a first (monster) step down this path.
Here's something I can try to help with. I'm sure there's a lot of research I need to do to get caught up, but this is a concrete goal I can work towards. -- Lyle
On Fri, 1 Aug 2008 11:18:28 -0700 Derek Wright <drupal@dwwright.net> wrote:
Once upon a time, in a post someone with time and motivation could surely find, Dries wrote something to the effect of:
"I'd be happy to switch to something other than CVS _if all the dependencies on CVS are safely removed and addressed_".
(approximate quote from memory).
- The #1 dependency on CVS is project_release.module. - The #2 dependency on CVS is all the CVS account creation stuff. - The #3 dependency on CVS are the CVS commit log viewing pages, links on project nodes, etc. - The best way to fix all of that is VersionControl API. - There are pages dedicated to what needs to happen to get us closer, already linked from Angie's wonderful document.
If all that work is done, d.o is running VersionControl API with
Surfing in look for a bunch of howtos I noticed how many projects switched from one rcs to another. All kind and all sizes of projects... And I wondered why drupal find so hard to switch. Then your mail came to my mind: dependency. Other projects "outsourced" the infrastructure for project management, drupal build its own. I was wondering what are the advantages of such approach. Joomla have a much less tied one. Plone is something in between Drupal and Joomla but still much nearer to Joomla approach than drupal. From my "use case" the only disadvantage I can see in a less tied approach with contrib is security support. This as more to due with the social/image aspect than the technical aspect. Other projects seems just to provide a window for contrib. Drupal seems to "patronize" contrib. But that's not going to make contrib really better unless you think you can force education on people. Dev that never felt the need of a rcs and are forced to use one will use it in a sloppy way with fewer advantages for the project than added nuisances. From _my_ point of view as a user and as a contrib I'd feel happy with Joomla approach as well. I don't see any reason to ask for a cvs account on drupal to develop my modules. I have my project infrastructure and if I hadn't one I could pick up one from the many offered, building up my preferred mix of bug tracking system, rcs, documentation system, ... I may be missing something... if so please tell me what could be the advantage for contrib and users to use drupal infrastructure for project management I don't get. Other than publicity what do I get from drupal infrastructure? Making it clear (to me and to everyone else) what are the advantages of using drupal infrastructure for project management would surely help. People will use it more and better. It would be easier to gather the forces to improve it. It would make it clearer the scope of having a "project" infrastructure and plan it for its real targets. I don't think that core has so many tie with project_release.module and cvs accounts. I do think that core could take a great advantage if we could use a DVCS. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
From _my_ point of view as a user and as a contrib I'd feel happy with Joomla approach as well. I don't see any reason to ask for a cvs account on drupal to develop my modules. I have my project infrastructure and if I hadn't one I could pick up one from the many offered, building up my preferred mix of bug tracking system, rcs, documentation system, ... I may be missing something... if so please tell me what could be the advantage for contrib and users to use drupal infrastructure for project management I don't get. Other than publicity what do I get from drupal infrastructure?
Making it clear (to me and to everyone else) what are the advantages of using drupal infrastructure for project management would surely help.
Feel free to contribute in whatever way you feel best serves your needs. Using the d.o infrastructure for project management does provide some real benefits to the user community as a whole and to individual projects. First of all, nobody has to worry about finding a service to use, or building their own. There are no RCS servers to maintain. Plus, there is a consistent interface to all of these tools across projects. In addition, the update_status module gets its information from drupal.org. If your module isn't hosted on d.o, then users of your module will not be informed of updates, whether these updates include security fixes, new features, bug fixes, etc. In addition, third party sites like drupalmodules that scrape drupal.org will also probably not know about your module. Less visibility often means less contributions from other developers. Plus, as you mentioned, the d.o security team only monitors projects hosted on the d.o infrastructure. Adam
On Thu, 7 Aug 2008 07:40:59 -0500 "Adam Light" <aclight@gmail.com> wrote:
On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
From _my_ point of view as a user and as a contrib I'd feel happy with Joomla approach as well. I don't see any reason to ask for a cvs account on drupal to develop my modules. I have my project infrastructure and if I hadn't one I could pick up one from the many offered, building up my preferred mix of bug tracking system, rcs, documentation system, ... I may be missing something... if so please tell me what could be the advantage for contrib and users to use drupal infrastructure for project management I don't get. Other than publicity what do I get from drupal infrastructure?
Making it clear (to me and to everyone else) what are the advantages of using drupal infrastructure for project management would surely help.
Feel free to contribute in whatever way you feel best serves your needs.
Using the d.o infrastructure for project management does provide some real benefits to the user community as a whole and to individual projects. First of all, nobody has to worry about finding a service to use, or building their own. There are no RCS servers to maintain. Plus, there is a consistent interface to all of these tools across projects.
Drupal could still offer cvs (svn) etc... avoiding the need to look around without forcing contrib to stick with "drupal way". I really don't find these advantages worth the effort and pain of the people maintaining project*. That's just me. Furthermore the only consistent interface I see is cvs. If you mean: information for users... the single project pages... that's what other projects like Joomla or plone are offering without the need of such a tight coupling with the rcs.
In addition, the update_status module gets its information from drupal.org. If your module isn't hosted on d.o, then users of your module will not be informed of updates, whether these updates include security fixes, new features, bug fixes, etc. In addition, third party sites like drupalmodules that scrape drupal.org will also probably not know about your module. Less visibility often means less contributions from other developers.
It doesn't mean it could be achieved with other means that will put a bit more work on contrib devs at the advantage of much less work on drupal infrastructure and much more freedom for contrib. We've rss, aggregators... and I think most drupal contrib have a drupal site. It doesn't seem that less coupling between the "community plumbing" aspect and the project management infrastructure is having an appreciable effect on other project flourishing of extensions. Furthermore I think that project management needs for core are quite different to the one of contrib. In this situation the "status quo" looks better than investing more resources into project* to support a different rcs. I still don't feel like an exception seeing more ties than opportunities in an even more structured project*. Am I?
Plus, as you mentioned, the d.o security team only monitors projects hosted on the d.o infrastructure.
As said... I think the "patronage" of sec team is the most valuable thing. I wonder if sec team actively scrutinise contrib modules or just coordinate fix in core and sec announcement for contrib. -- Ivan Sergio Borgonovo http://www.webthatworks.it
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Sergio Borgonovo schrieb:
On Thu, 7 Aug 2008 07:40:59 -0500 "Adam Light" <aclight@gmail.com> wrote:
On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
From _my_ point of view as a user and as a contrib I'd feel happy with Joomla approach as well. I don't see any reason to ask for a cvs account on drupal to develop my modules. I have my project infrastructure and if I hadn't one I could pick up one from the many offered, building up my preferred mix of bug tracking system, rcs, documentation system, ... I may be missing something... if so please tell me what could be the advantage for contrib and users to use drupal infrastructure for project management I don't get. Other than publicity what do I get from drupal infrastructure?
Making it clear (to me and to everyone else) what are the advantages of using drupal infrastructure for project management would surely help. Feel free to contribute in whatever way you feel best serves your needs.
Using the d.o infrastructure for project management does provide some real benefits to the user community as a whole and to individual projects. First of all, nobody has to worry about finding a service to use, or building their own. There are no RCS servers to maintain. Plus, there is a consistent interface to all of these tools across projects.
Drupal could still offer cvs (svn) etc... avoiding the need to look around without forcing contrib to stick with "drupal way". I really don't find these advantages worth the effort and pain of the people maintaining project*. That's just me.
Great, so can you please get lost now? Your inane comments on this list have annoyed me for the longest time now. Since you probably don't have the grace to disappear I'll solve the problem my way, filterlist amended. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFImwswfg6TFvELooQRAgL4AKCuxl7pAwaNBftak8yzUWfmGcVG9wCfRNs+ OreHW6KX9a1Xlf0KaeX/XmU= =zhXa -----END PGP SIGNATURE-----
On Aug 7, 2008, at 7:48 AM, Gerhard Killesreiter wrote:
Since you probably don't have the grace to disappear I'll solve the problem my way, filterlist amended.
Even if he frequently makes inane comments that we regularly disagree with, it doesn't mean we should ban him from the list. While I disagree with the thrust of his latest contribution, I think he raises questions that need real answers, not a heavy handed "get lost". Thanks to Adam and Nat for actually answering the questions, which I thought were valuable messages for this list to read and consider. Cheers, -Derek (dww)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb:
On Aug 7, 2008, at 7:48 AM, Gerhard Killesreiter wrote:
Since you probably don't have the grace to disappear I'll solve the problem my way, filterlist amended.
Even if he frequently makes inane comments that we regularly disagree with, it doesn't mean we should ban him from the list.
I never said I would. I've put him in my personal mail filter. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFImxjyfg6TFvELooQRAgNZAJ9VxzoupTRLenjvXaSFeU+9h1p5bgCeINqc D5TB770545ho2beHBlorPu4= =Hlt+ -----END PGP SIGNATURE-----
Ivan Sergio Borgonovo wrote:
It doesn't seem that less coupling between the "community plumbing" aspect and the project management infrastructure is having an appreciable effect on other project flourishing of extensions.
For me there's several reasons why the centralised project* infrastructure is an extremely good thing. In most cases, other projects don't have modules which are in any way as interdependent as Drupal's - not just CCK and Views, but modules like Token, VotingAPI, imagecache and suites like ecommerce and ubercart where there's a tonne of dependent modules as well, many many others. Having all these in one place is a massive benefit, and encourages inter-project collaboration. Another issue is that if you use a popular module and the developer is hit by a bus, then assuming it's used by some other people with enough experience to take it over and enough of a need for it, there's a fair chance the module will be adopted by a new maintainer - not on some random website that you might find via searching a year later when you're looking to upgrade, but right in the same spot. This is in contrast to jQuery plugins where there'll be a howto on one site, followed by a plugin on another site, then a different version of the plugin on someone elses site - none of which have clear version compatibility - I use jQuery as an example because they actually use project* on jquery.com for the central project browsing minus the CVS integration. While core development is a very different process from contrib, nearly everyone pointing out how different it is has failed to mention that almost as many people contribute core patches as have CVS accounts on drupal.org - for some their patch is their one and only contribution to Drupal before disappearing again. Not to mention core uses exactly the same infrastructure as contrib for packaging etc. - meaning the infrastructure work would be about as much. Ivan:
I wonder if sec team actively scrutinise contrib modules or just coordinate fix in core and sec announcement for contrib.
The sec team doesn't go reviewing random contrib modules - there's about as many contribs released per day as there are security team members, however there is active support for security issues in contrib once reported, so it's more than just releasing an announcement. Nat
On Thursday 07 August 2008 09:26:43 Ivan Sergio Borgonovo wrote:
On Thu, 7 Aug 2008 07:40:59 -0500
Furthermore I think that project management needs for core are quite different to the one of contrib.
This is the only point that I think has much merit. Again, I'm not advocating anything, but as our vcs and project management systems evolve, I think we ought to keep the possibility of using different vcs mechanisms for core and contrib in mind. There are certainly drawbacks, but given that the needs and workflows are pretty different, it could, on balance, be beneficial to reflect that in the underlying organization of the vcs.
Dww: Thank you for not bad mouthing Ivan. There is nothing wrong with looking at other projects and their methods. Personally, I think Drupal's is pretty freaking good because the community is massive, and I don't think it's 100% the software, so something is working there. However, I feel like Drupal is also becoming more of an app framework than a CMS, and I think it has a bad architecture for an app framework. I use Django when I'm not building a CMS. I use Wordpress when I need a blog. I know it is probably heresy, but why do we have to eat our own hippo food (a total project management system) in drupal. Drupal is a CMS! There are many excellent project management / vcs suites out there (JIRA and trac come to mind). I would much rather see a tight integration into drupal.org with one of them, than go the direction of continuing the development of something which is really just maintained for d.o. and gives nothing back to the rest of the software community while eating up resources. What do you guys think? Would it be cheaper to actually just re-implement the project management tools in trac and then write the glue code in python to integrate with d.o.? Best, J
On Aug 7, 2008, at 10:46 AM, Jacob Singh wrote:
Would it be cheaper to actually just re-implement the project management tools in trac and then write the glue code in python to integrate with d.o.?
It's funny you ask... http://groups.drupal.org/node/1047 Enjoy, -Derek (dww)
participants (28)
-
Adam Light -
Addison Berry -
Adrian Rossouw -
Adrian Simmons -
Angela Byron -
Chris Johnson -
Derek Wright -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
Gordon Heydon -
Ivan Sergio Borgonovo -
Jacob Singh -
Jason Flatt -
Karoly Negyesi -
Konstantin Käfer -
Larry Garfield -
Lyle Mantooth -
mark burdett -
Michael Prasuhn -
Moshe Weitzman -
Nancy Wichmann -
Nathaniel Catchpole -
Owen Barton -
Sam Boyer -
Sean Burlington -
Steve Scotten -
Victor Kane