bzr and Drupal. We now have a bzr mirror of the core. It's easier for a group of people to work on a bigger change in their own branch and submit a final diff. (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr branch, too and then instead of patches we may submit a link to a bzr branch instead of a patch file but this is not so important. We will provide and advertise a readonly bzr mirror for all contrib directories. If the module maintainer decides that he he does not want to deal with CVS but uses bzr instead, he will have a checkbox in project module to indicate that (or if we do not want project change, just text that). If it's a bzr maintained module then you can contribute two ways: a) send in patches (like now) b) from the bzr mirror, create your branch and submit a link to the maintainer. When the maintainer wants to commit changes back to the repo, he merges changes and pushes that to a private branch. When this push happens, a simple script is run, which commits these changes back to cvs, and from there we mirror to bzr and the cycle is complete. The problem is -- how we avoid conflicts? Simply, if a module is bzr maintained, then we make it clear that you should not commit into the CVS repository dir by the means of CVS. Either submit a patch (as you do now) or use bzr but do not commit into that dir. Ideally, cvs.drupal.org rejects this kind of commit by the means of a pre-commit script. Lacking that, the bzr to cvs script will take care of it. Then this script needs to track of the revision of the cvs revision of the files in the readonly bzr mirror (first ancestor): # check out the first ancestor cvs co foo -r$known_revision # make sure the cvs is in that state cvs commit # bring in the new/changed files bzr pull $maintainers_private_branch # make sure CVS knows about new files cvs add * # put the log into an obscure named file bzr log $maintainers_private_branch -r -1 >__bzr__log # reuse that for cvs log message cvs com -F __bzr__log Yes, that's the actual script. Advanced versions will be able to branch for Drupal versions. Even that should not be too hard, because the bzr mirrors (including the maintainers_private_branch) will have directories modules/eventrepeat/4.6 -- one dir for every Drupal major version. Updating the readonly bzr mirror is easy: cvs up -dP bzr commit Probably the scripts will be written in PHP and linked through the database -- after all, you need store somehwere the known_revision and maintainers_private_branch. The __bzr__log also should be saved and reused when commit in the readonly space. Or to maintain simplicity maybe we could get away even with some bash scripts which store info in text files. Caveat: I am no expert of that. (note. file additions and removals needs to handled. Maybe tailor will be used here.) If the module is a CVS maintained one, then those that are on the bright side can _still_ use the readonly bzr mirror only they are not submitting bzr branch links but patches. Let's see some benefits: The necessary scripts are simple. If someone wants to run cvs update -- (s)he can do that. If a module/theme/translator maintainer is sick of cvs -- there is bzr. Also, a web upload interface is coming for bzr. If a module/theme/translator maintainer wants to use cvs -- (s)he does not need to face bzr yet his/her contributors can use that and submit patches. What's lost? If a module is bzr maintained then you can't just walk in and do an update of the module. The maintainers' responsibility is bigger. Solution? Multiple maintainers with a $maintainers_private_branch for each maintainer. You still can't just walk in, but there always will be someone who can commit your change. Note that this is pretty rare, as most module maintainers do not like if you commit into their directory in the current situation. One more thing: there should be another privilege level, they can commit against any module. Note that we do not need to change _anything_ in the modules currently used Drupal.org! Still CVS is the common denominator This is a plan which needs time. Also, bzr itself needs some time. I do not plan on posting the whole Drupal community through drupal.org until bzr 2.0 is out next spring.
My major issue with BZR is source repository browsing. We need a central web based interface to browse the repository, and do diffs and the like. Applications like this exist for both svn and cvs, but not for bzr. There is a php library for svn that would allow us to directly integrate it into Drupal (which would be great for a project management tool. Think trac in php, but with Drupal). So long as the files are in one location, I'm happy .. but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script. On 24 Nov 2005, at 8:32 AM, Karoly Negyesi wrote:
bzr and Drupal.
We now have a bzr mirror of the core. It's easier for a group of people to work on a bigger change in their own branch and submit a final diff. (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr branch, too and then instead of patches we may submit a link to a bzr branch instead of a patch file but this is not so important.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Agreed. Subversion makes branching and merging much easier than in CVS, which I understand is one of the main things people like about the non-CVS options being bandied about. You don't need a fully distributed archive in order to maintain multiple branches! The KDE project is several times the size of Drupal and they manage just fine with Subversion. Subversion also beats everything out there except CVS for adoption. The toolchain is there, the mindshare is there, and new people coming to Drupal are far more likely to be able to say "Subversion, oh I know that" than with darcs, bzr, git, or whatever. bzr only increases the barrier to entry for new developers. On Thursday 24 November 2005 02:11 am, Adrian Rossouw wrote:
My major issue with BZR is source repository browsing.
We need a central web based interface to browse the repository, and do diffs and the like. Applications like this exist for both svn and cvs, but not for bzr.
There is a php library for svn that would allow us to directly integrate it into Drupal (which would be great for a project management tool. Think trac in php, but with Drupal).
So long as the files are in one location, I'm happy .. but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script.
On 24 Nov 2005, at 8:32 AM, Karoly Negyesi wrote:
bzr and Drupal.
We now have a bzr mirror of the core. It's easier for a group of people to work on a bigger change in their own branch and submit a final diff. (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr branch, too and then instead of patches we may submit a link to a bzr branch instead of a patch file but this is not so important.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
2005/11/24, Larry Garfield <larry@garfieldtech.com>:
Subversion also beats everything out there except CVS for adoption. The toolchain is there, the mindshare is there, and new people coming to Drupal are far more likely to be able to say "Subversion, oh I know that" than with
And, i used to say, those who don't know SVN often know CVS and can switch easely... That's why SVN is a good compromission imho.
darcs, bzr, git, or whatever. bzr only increases the barrier to entry for new developers.
However, let's keep an eye on others alternatives... So we'll be fully ready when time will come to another (or better) choice ;-)
Suggest: why not add a poll on http://drupal.org to ask people what's their favorite CSM..? We'll have so a good idea how ready future dev' are ready to switch to something else and what.. -- vi is a real WYSIWYG editor: you see text, you get text.
And, i used to say, those who don't know SVN often know CVS and can switch easely... That's why SVN is a good compromission imho.
My concern are developers, translators and themers who know neither. I'd like to provide a web service so they do not need to know either.
Suggest: why not add a poll on http://drupal.org to ask people what's their favorite CSM..? We'll have so a good idea how ready future dev' are ready to switch to something else and what..
I think there is no need. Here's why: you have people who are working on making bzr for Drupal happen, at this moment it's hunmonk, chx -- and jblack from the bzr project itself. No matter what you poll, you need people to get things rolling. And note that with my battle plan I am not forcing _any_ change. I plan to offer bzr, if you like it, that's great, but if you do not, so be it. Again and again I will state that SVN solves none of our growing problems. It could if we would change dramatically our workflow but I do not think we are ready for that. I set up the bzr mirror of core so that people who want to work together on something bigger just can. A loose team of contributors needs a distributed RCS IMO. So if Drupal goes to SVN, my battle plan applies just the same. But again, that needs work, and so far I have seen only talk, including myself. I am sold to the bzr idea and actually working on it, and yes the bzr.module will happen sooner than later.
Gildas COTOMALE wrote:
Suggest: why not add a poll on http://drupal.org to ask people what's their favorite CSM..? We'll have so a good idea how ready future dev' are ready to switch to something else and what..
It qould be quite pointless as the popular opinion does not matter at all as is often the case in software development. If Dries doesn't like it it won't get used by the project. Of course people can set up their own mirros using whatever tool they like. In the end all what counts is the quality of the code. Cheers, Gerhard
Gerhard Killesreiter wrote:
Gildas COTOMALE wrote:
Suggest: why not add a poll on http://drupal.org to ask people what's their favorite CSM..? We'll have so a good idea how ready future dev' are ready to switch to something else and what..
It qould be quite pointless as the popular opinion does not matter at all as is often the case in software development.
I agree with Gerhard here. I wouldn't want for us to pick a version control software based on popular opinion (nor, "hey it works fine for so-and-so" for that matter), but rather how well it addresses *our* specific needs as developers for Drupal. Probably the best place to start this conversation is to establish answers the following questions (and probably some others), and choose a product based on that: 1. What are our major gripes about CVS and where has CVS failed us? 2. On the flip-side, what are some cool things about CVS that we like and want to make sure the next package has? 3. What types of development ventures have we embarked on in the past that were difficult to do with CVS and patches? 4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that would help ease development? For my part: 1. I've been bitten by the fact that the only way to grab a snapshot of the code at a certain date and time is by timestamp. If there were 50 commits to Drupal one day, and I want to know "What did the source look like right before patch #23344 was committed?" it's extremely difficult to do that. This could be lack of knowledge of CVS on my part, but I remember asking in #drupal about this and basically being told, "you're screwed." (though killes suggested a workaround that seemed to work in my case). 2. Morbus is going to slap me, but I really like the convenience of TortoiseCVS. *DUCK* I also like the fact that I can browse the CVS repo on the web and do quickie diffs between versions to spot changes. 3. Forms API. This was a huge, sweeping change against almost every file in Drupal. We were trying to have 10 or more developers each changing little chunks here and there and rolling them into one huge monster patch. This was an absolute nightmare before we had a SVN repository of our own to commit to so we had something stable to commit against. 4. I don't really have enough knowledge in this area to comment on this. The only thing I could think of is CSL, Bryght, and Drupal.org all sharing the same RCS, but I don't know what specific advantages that would have only that it would be more "unified." -Angie
Angie I fully agree with you. chx is to be commended for taking the initiative of introducing us to bzr, but that should not sway is on its own. We should really evaluate what is out there, and make an informed decision. We should see what other open source projects are doing too, and learn from their experience. Dries: you should take action on this. You have said you want to stay on CVS. Fair enough. But what about: - Are there any pains with CVS? - Are there better features elsewhere? - Do we benefit from a new tool? Discuss more, form a team, argue, pros/cons, ...etc. This is what we need. This is how the discussion should start, not as a forgone conclusion or preempting the issue.
I agree with Gerhard here. I wouldn't want for us to pick a version control software based on popular opinion (nor, "hey it works fine for so-and-so" for that matter), but rather how well it addresses *our* specific needs as developers for Drupal.
Probably the best place to start this conversation is to establish answers the following questions (and probably some others), and choose a product based on that:
1. What are our major gripes about CVS and where has CVS failed us?
2. On the flip-side, what are some cool things about CVS that we like and want to make sure the next package has?
3. What types of development ventures have we embarked on in the past that were difficult to do with CVS and patches?
4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that would help ease development?
Op vrijdag 25 november 2005 00:17, schreef Angie Byron:
1. What are our major gripes about CVS and where has CVS failed us?
CVS forces everyone to keep patches in a queue up to date (revisions patch). CVS does nothing to help ease this pain. CVS has a very hard to grok concept. It requires users to get a complete new idea of file management.
2. On the flip-side, what are some cool things about CVS that we like and want to make sure the next package has?
The amount of tools available for it. Not only GUIS, also scripts and all that.
3. What types of development ventures have we embarked on in the past that were difficult to do with CVS and patches?
Grouped efforts on a certain issue. Forms API indeed. Usability improvments. Most often a patch does not "explain" anything in usability improvements, because patches are really "hardcore developers communication". Distribution management. This has not even been tried.
4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that would help ease development?
Manage distributions and "flavours" of Drupal. Make a patch, then let it do its own pimping (instead of me going around IRC, jabber, mail, bumping issues etc). Make it possible to let a patch linger in a queue for a while, yet it can still be applied. Allow me to branch off (core) modules to work on that for * my own projects (yet someone might be interested in that work too) * improvement of a core project. Patches alone are unfit for large changes * Distributions. They might want slightly modified version of stuff. Or additional files Ber
Bèr Kessels wrote:
Op vrijdag 25 november 2005 00:17, schreef Angie Byron:
1. What are our major gripes about CVS and where has CVS failed us?
CVS forces everyone to keep patches in a queue up to date (revisions patch).
I fail to see how I wouldn't have to do that with any other tool. Are the merge algorithms so much better?
CVS does nothing to help ease this pain.
What do other systems do?
CVS has a very hard to grok concept. It requires users to get a complete new idea of file management.
Hmm, not really. I have to admit that I hardly understand how CVS works, yet I am able to use it.
2. On the flip-side, what are some cool things about CVS that we like and want to make sure the next package has?
The amount of tools available for it. Not only GUIS, also scripts and all that.
3. What types of development ventures have we embarked on in the past that were difficult to do with CVS and patches?
Grouped efforts on a certain issue. Forms API indeed.
This would have been possible with CVS as well.
Usability improvments. Most often a patch does not "explain" anything in usability improvements, because patches are really "hardcore developers communication".
Well, code improvements are for hardcore developers to understand. I don't get the point you are trying to make.
Distribution management. This has not even been tried.
Right. I actually question if this will work with Drupal and its current rather tight access to core cvs. if you want to make this access more open, you should discuss this and not your pet RCS.
4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that would help ease development?
Manage distributions and "flavours" of Drupal. Make a patch, then let it do its own pimping (instead of me going around IRC, jabber, mail, bumping issues etc).
hä?
Make it possible to let a patch linger in a queue for a while, yet it can still be applied.
See above, if there are changes in core, any RCS will have to merge it and might fail.
Allow me to branch off (core) modules to work on that for * my own projects (yet someone might be interested in that work too) * improvement of a core project. Patches alone are unfit for large changes * Distributions. They might want slightly modified version of stuff. Or additional files
This can all be done with CVS, IIRC. Making such erroneous claims won't really increase your chance to get any change through. The improvements I'd be interested in is: - web frontend for uploading new versions for translators and theme designers (if they wish to use it) - being able to lock out other people from my projects or rather allow specific peopel write access to my projects. - automatic testing of applicability of mailed/uploaded patches. - also working offline and making patches against the main repository. Those are some of the things that would _really_ help Drupal development because those refer to things we do all day. The forms API thing happened once in over four years and I don't see any such large changes coming up soon again (and it could have been done with CVS too). So please: People who want us to change away from CVS to anywhere should provide _real_, _relevant_ use cases and advantages and not FUD. Cheers, Gerhard
So please: People who want us to change away from CVS to anywhere should provide _real_, _relevant_ use cases and advantages and not FUD.
For what it's worth, I'm in the killes camp. bzr = whooptidoo. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
I did *not* say that other tools could do this better. I *only* provided a *fair and unpoluted* range of answers. Developers (or technical people, in general actiually) tend to jump to technical issues right away, yet often fail to look at the problem from a global, unpoluted viewpoint. I tried to answer the questions about what we need and what we want, about what our current problems were, from an unbiased point. I tried to ignore any thing like "is it there, is it technically possible, or does Foo do this better then Bar". I tried to first get that top level idea right: answer to the question "what do we need an why" once, only after we truly know what we need, can we look which tools fit into that need best. Its what designers (technical designers, engineers, not webdesigners or graphical designers!) call "top-down approach", or "methodological approach", or even "morphological design"). It is the methodology used by NASA to design a rocket, by developers of nuclear plants and even by developers of a ballpointpen. Ber
Bèr Kessels wrote:
I tried to first get that top level idea right: answer to the question "what do we need an why"
Thanks. This too is where I was going with that line of questioning. If someone answers with, "I like the way Subversion does blah blah better," that isn't quite the point. The point is to basically perform a mini-SWOT analysis of our current situation, and after having a clear overall view of where we are and where we'd like to be, *then* research and choose a tool based on that (or stick with CVS, if that's deemed most appropriate). Versus the more "bottom-up" approach where everyone starts voicing support for their own pet favourite tool, and then us all having to worry about how we'll have to alter our workflow to fit that tool. Probably there will be features thought of that aren't in *any* tool, but at least we'll have a clear idea of what our needs are and where we needed to compromise in order to choose a tool that met most of them. -Angie
Op vrijdag 25 november 2005 17:03, schreef Angie Byron:
Bèr Kessels wrote:
I tried to first get that top level idea right: answer to the question "what do we need an why"
Thanks. This too is where I was going with that line of questioning.
If someone answers with, "I like the way Subversion does blah blah better," that isn't quite the point. The point is to basically perform a mini-SWOT analysis of our current situation, and after having a clear overall view of where we are and where we'd like to be, *then* research and choose a tool based on that (or stick with CVS, if that's deemed most appropriate). Versus the more "bottom-up" approach where everyone starts voicing support for their own pet favourite tool, and then us all having to worry about how we'll have to alter our workflow to fit that tool.
Probably there will be features thought of that aren't in *any* tool, but at least we'll have a clear idea of what our needs are and where we needed to compromise in order to choose a tool that met most of them.
Angie, I think this might be a good route to take, but to do so, this should be taken offline, i think and put onto a wiki. http://www.webschuur.com/node/332 I did that, and i hope to spend some more time on collecting the various issues ideas and wishes, and publish them there. Ber
To add to the list Ber made:
Op vrijdag 25 november 2005 00:17, schreef Angie Byron:
1. What are our major gripes about CVS and where has CVS failed us?
No such thing "cvs rename" No such thing as "cvs move" - which make it laborious to correct mistakes and design changes No versioning of directories - which means empty directories (after mistakes or design changes) stay in the repository until someone with file-system level access cleans them up They're small niggles I know, but they really drag on day-to-day tasks.
2. On the flip-side, what are some cool things about CVS that we like and want to make sure the next package has?
Existing integration with drupal.org project module, packaging scripts. Web front end on drupal.org. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
No such thing "cvs rename" No such thing as "cvs move" - which make it laborious to correct mistakes and design changes
I agree, but not that they're "day to day tasks".
No versioning of directories - which means empty directories (after mistakes or design changes) stay in the repository until someone with file-system level access cleans them up
Aesthetically, ok. In use? -dP and they'll never bother you again. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
Aesthetically, ok. In use? -dP and they'll never bother you again. Er, sure. But what I actually had in mind was the theme_styles directory that existed for a while when phptemplate started to get popular - people kept adding styles to it even after it was decided to keep them with their parent themes. Then having to go through all the pain of moving them afterwards. It's a small picky thing, but it required someone with filesystem access to remove it.
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Hi all, We (xaraya) recently had to change our SCM due the the BitKeeper licence issue and did quite a bit of research on the matter before settling on monotone. Our development processes (we got spoiled with a distributed system) are significantly different than Drupal's, but I thought I might throw a link to Marcel's comparison for a little insight. http://www.xaraya.com/~marcel/scm_compare.html/ Just to note, our thought process came down to SVN and Monotone, but went with MT due to the distributed method our development. Just trying to help a little... -- John Cox http://wyome.com http://www.xaraya.com
At 4:56 PM -0500 26/11/05, John Cox wrote:
thought I might throw a link to Marcel's comparison for a little insight.
That's an amazing comparison! I don't suppose there's any chance of Marcel having a look at bzr and updating that page? ...Richard.
2005/11/25, Angie Byron <drupal-devel@webchick.net>:
1. What are our major gripes about CVS and where has CVS failed us?
CVS authentication via pserver sends password as plain text. SVN uses WebDAV (over HTTPS) and it can plug in with apache DB authentication (PostgreSQL or MySQL) with mod_auth_*. I am thinking in a SQL JOIN of drupal site users by drupal developers write access to repository. I have used CVS in my projects by enough time but since I use SVN it is a little better. By the way, I am lost no change using the tool cvs2svn. -- Rafa Couto (caligari) mailto:rafacouto @gmail.com Linux user #99126 (http://counter.li.org)
On 25 Nov 2005, at 12:00 PM, Rafa Couto wrote:
SVN uses WebDAV (over HTTPS) and it can plug in with apache DB authentication (PostgreSQL or MySQL) with mod_auth_*. I am thinking in a SQL JOIN of drupal site users by drupal developers write access to repository. Yeah.
And we can tie it into the site nicely with the subversion lib for php We could even have variable permissions on different parts of the path. (ie: only allow these people to commit to this directory) It could even be tied to Roles in drupal, giving people in a different role more access to certain parts. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
We could even have variable permissions on different parts of the path. (ie: only allow these people to commit to this directory) Yeah, which means we can actually use branches for collaborative development - much less of a need for bzr...
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On 25 Nov 2005, at 7:07 PM, Adrian Simmons wrote:
Adrian Rossouw wrote:
We could even have variable permissions on different parts of the path. (ie: only allow these people to commit to this directory) Yeah, which means we can actually use branches for collaborative development - much less of a need for bzr... I think we could actually host all of drupal in the same repository, using differing permissions on each of the paths.
So only dries would have access to /drupal , and have other people have access to /contributions, and have yet another group of people with access to the middle tier /supported. And this could all be managed from within drupal (although I freely admit that that might not be desired). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script. Indeed, I really think CVS actually does harm in the confusion it causes for new users. SVN is a little bit more intuitive, and it's easier to fix mistakes (versioned directories, "svn move" and "svn rename").
But we are left with the same questions: Will Dries ever approve the move to SVN? What would it take for that to happen? What do we need to do to make it happen? I have to point out that we are probably already loosing out because of sticking with CVS. I for one don't use drupal.org's CVS for my development (one unpopular module and one reasonably popular theme), I keep everything in a local SVN repository, do all the changes in that then "svn export" and upload that to drupal.org CVS. It's more work than it should be but less painful than working with CVS directly. I suspect I'm not the only one doing this. bzr is interesting, and I will hopefully find the time to play with it, but it's not mature, and I still think we'd be better of allowing some branches to be created for collaborative work (such as the form-API). I believe it's possible to limit access to parts of the repository with SVN, so perhaps a limited set of people could be granted access to a specific branch, this would also work in nicely with Adrian's DEP suggestion, a DEP would be required before the branch is created. I really feel we're not making proper use use of current versioning systems ability to facilitate collaboration, it might be nice to see what we can do with that before going for something like bzr. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Adrian Simmons wrote:
Adrian Rossouw wrote:
but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script. Indeed, I really think CVS actually does harm in the confusion it causes for new users. SVN is a little bit more intuitive, and it's easier to fix mistakes (versioned directories, "svn move" and "svn rename").
But we are left with the same questions:
Will Dries ever approve the move to SVN? What would it take for that to happen? What do we need to do to make it happen?
I didn't really follow the thread so excuse me if I am missing the point. In my opinion, Drupal is better using CVS than SVN. With SVN, you get a new revision number on every commit. That's fine with compact projects like Drupal core. But that's not so fine if commits done to themes, modules, etc are done in the same repository. It will make it hard for everyone to follow what's going on. This is especially true since I have noticed that a few developers still don't understand how to make grouped commits and keep on commiting 100s files one at a time... With SVN and this kind of behavior, you get a +100 revision number on the main repository. So unless you create one repository per module, theme, projects, you are safer using CVS. -- Bertrand Mansion Mamasam Tel : +33 1 48 89 88 26 http://www.mamasam.com Creative Internet Solutions
On 24 Nov 2005, at 3:42 PM, Bertrand Mansion wrote:
In my opinion, Drupal is better using CVS than SVN. With SVN, you get a new revision number on every commit. That's fine with compact projects like Drupal core. But that's not so fine if commits done to themes, modules, etc are done in the same repository. It will make it hard for everyone to follow what's going on.
It's just a number. It doesn't matter if the numbers don't follow on each other inside the directory. Our versioning will be based on the path .. ie : branches/4.6/modules/ modulename. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Thursday 24 November 2005 07:42 am, Bertrand Mansion wrote:
In my opinion, Drupal is better using CVS than SVN. With SVN, you get a new revision number on every commit. That's fine with compact projects like Drupal core. But that's not so fine if commits done to themes, modules, etc are done in the same repository. It will make it hard for everyone to follow what's going on.
The KDE project passed its 10,000th commit to its SVN repository a few months after migrating from CVS. So far it's been smooth sailing. The commit number has no real significance. If anything SVN makes this easier since commits are project atomic. (You don't commit each file individually; you commit all your inter-related changes as a single atomic action.)
This is especially true since I have noticed that a few developers still don't understand how to make grouped commits and keep on commiting 100s files one at a time... With SVN and this kind of behavior, you get a +100 revision number on the main repository.
So unless you create one repository per module, theme, projects, you are safer using CVS.
There are, I think, valid arguments to do that anyway, regardless of the SCM in use, but keeping the commit count number low is not one of them. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script.
Indeed, I really think CVS actually does harm in the confusion it causes for new users. SVN is a little bit more intuitive, and it's easier to fix mistakes (versioned directories, "svn move" and "svn rename").
But we are left with the same questions:
Will Dries ever approve the move to SVN? What would it take for that to happen? What do we need to do to make it happen?
This is quite easy to answer. Software support is not in place (drupal.org commit tracking, project module, etc) for SVN. First this needs to be done for a version management system, before a switch can be considered. Goba
On 26 Nov 2005, at 11:43 PM, Gabor Hojtsy wrote:
but I really do think we need to give cvs the boot. SVN is far simpler to comprehend, and script.
Indeed, I really think CVS actually does harm in the confusion it causes for new users. SVN is a little bit more intuitive, and it's easier to fix mistakes (versioned directories, "svn move" and "svn rename").
But we are left with the same questions:
Will Dries ever approve the move to SVN? What would it take for that to happen? What do we need to do to make it happen?
This is quite easy to answer. Software support is not in place (drupal.org commit tracking, project module, etc) for SVN. First this needs to be done for a version management system, before a switch can be considered.
According to Dries, we need to first convert cvslog.module From how I understand the module, there's a set of scripts which manipulate the cvslog table, when triggered by cvs commits. We would (simply?) have to rewrite these commit scripts to populate the tables on svn commits. That's my 2 minute overview of the problem. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
We would (simply?) have to rewrite these commit scripts to populate the tables on svn commits.
As well as code that allows us to import an existing (entire) repository. -- Dries Buytaert :: http://www.buytaert.net/
On 27 Nov 2005, at 12:10 PM, Dries Buytaert wrote:
We would (simply?) have to rewrite these commit scripts to populate the tables on svn commits.
As well as code that allows us to import an existing (entire) repository.
That already exists.. It's how the svn mirror got initialised. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
We would (simply?) have to rewrite these commit scripts to populate the tables on svn commits.
As well as code that allows us to import an existing (entire) repository.
That already exists..
To import a SVN repository into the cvslog module's database tables? -- Dries Buytaert :: http://www.buytaert.net/
On 24.11.2005 09:11, Adrian Rossouw wrote:
My major issue with BZR is source repository browsing.
We need a central web based interface to browse the repository, and do diffs and the like. Applications like this exist for both svn and cvs, but not for bzr.
http://google.com/search?q=bzrweb ? -- ax Il n'est de problème qu'une absence de solution ne sache résoudre. QUEUILLE
On 24 Nov 2005, at 07:32, Karoly Negyesi wrote:
We now have a bzr mirror of the core. It's easier for a group of people to work on a bigger change in their own branch and submit a final diff. (hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr branch, too and then instead of patches we may submit a link to a bzr branch instead of a patch file but this is not so important.
I do not plan to use bzr at this point. (Please note that this is a chx-ism, and not something I approved up front.) Furthermore, I'll continue to make changes to contributed projects using CVS, whether they are "bzr maintained" or not. The setup should not impose restrictions on anyone's workflow. Right now, it seems to complicate collaboration by forcing people to use bzr. If they can't co-exist, bzr is not a viable solution, and I will not accept the project module and CVS changes it takes. -- Dries Buytaert :: http://www.buytaert.net/
Eventually, Dries may use a bzr
I do not plan to use bzr at this point. (Please note that this is a chx-ism, and not something I approved up front.)
I emphasize then "eventually" and "may".
Furthermore, I'll continue to make changes to contributed projects using CVS, whether they are "bzr maintained" or not. The setup should not impose restrictions on anyone's workflow.
Here is an addon then: When there is a cvs commit to a 'bzr maintained' module, the maintainer can decide whether he likes it or not and if he does like it, then he can issue an update of the readonly bzr mirror. The maintainer now needs to issue a bzr merge so that his branch contains the cvs update, too. bzr merge is excellent in handling three ways merges so there should not be a problem. As the typical way to contribute to someone else's project is submitting patches in the issue queue, this won't be necessary often. Note that the current situation is very similar: if you are working on your local checkout and someone does a commit against your module then you need to merge that. bzr merge is just better for this task. Regards NK
On 24 Nov 2005, at 10:48, Karoly Negyesi wrote:
I do not plan to use bzr at this point. (Please note that this is a chx-ism, and not something I approved up front.)
I emphasize then "eventually" and "may".
I know. I just wanted to point out that: 1. I won't switch to bzr (yet), and that 2. bzr is not officially supported (yet). I actively used darcs for a couple months. It looked exciting in the beginning, but even after a while, I could not get used to it and I decided to stick with CVS. Having to adapt your workflow only to find out it isn't what you hoped for can be frustrating. I still use darcs occasionally because of a research project I'm involved in. Also, I know that bzr is not darcs, and that bzr has some functionality that is sorely missing in darcs. The point is that I'm somewhat reluctant to go through this again. That said, the bzr repository makes for an interesting experiment, and I understand the potential benefit of a distributed model in the context of Drupal (it had big impact on Linux kernel development). If bzr gets support within the Drupal community, we could consider hosting the bzr repository ourselves and actively supporting it. If it doesn't take off, no harm done. We'll see how it goes. :-) In the mean time, I'll toy with bzr a little, and keep an eye on how it gets used within the Drupal community. Hopefully that clarifies my take on this, -- Dries Buytaert :: http://www.buytaert.net/
I "branched" upload to make it a full blown modular file system. It now lives in CVS contribs. Recently some developers showed interest, it seems this porject is taking off. I think this might be an interesting testcase, because I think these useacases is exactly what BZR is good at. If someone can hold my hand while getting this "contrib" out of CVS and into that BZR, we have a nice place to work, we can see how well bzr takes off. And in the end we can evaluate this. Ber Op donderdag 24 november 2005 11:23, schreef Dries Buytaert:
On 24 Nov 2005, at 10:48, Karoly Negyesi wrote:
I do not plan to use bzr at this point. (Please note that this is a chx-ism, and not something I approved up front.)
I emphasize then "eventually" and "may".
I know. I just wanted to point out that:
1. I won't switch to bzr (yet), and that 2. bzr is not officially supported (yet).
I actively used darcs for a couple months. It looked exciting in the beginning, but even after a while, I could not get used to it and I decided to stick with CVS. Having to adapt your workflow only to find out it isn't what you hoped for can be frustrating. I still use darcs occasionally because of a research project I'm involved in. Also, I know that bzr is not darcs, and that bzr has some functionality that is sorely missing in darcs. The point is that I'm somewhat reluctant to go through this again.
That said, the bzr repository makes for an interesting experiment, and I understand the potential benefit of a distributed model in the context of Drupal (it had big impact on Linux kernel development). If bzr gets support within the Drupal community, we could consider hosting the bzr repository ourselves and actively supporting it. If it doesn't take off, no harm done. We'll see how it goes. :-) In the mean time, I'll toy with bzr a little, and keep an eye on how it gets used within the Drupal community.
Hopefully that clarifies my take on this,
-- Dries Buytaert :: http://www.buytaert.net/
Karoly Negyesi wrote:
we may submit a link to a bzr branch instead of a patch file but this is not so important. I think that is actually a flaw - someone's web site goes down and suddenly you can't test there work. Code could get lost to the project in some instances. I think we'd always want to specify a patch should be provided as well as a link.
This is all just experimentation at the moment though :) -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
participants (17)
-
Adrian Rossouw -
Adrian Simmons -
Angie Byron -
Axel Kollmorgen -
Bertrand Mansion -
Bèr Kessels -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
Gildas COTOMALE -
John Cox -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Morbus Iff -
Rafa Couto -
Richard Archer