A Git mirror for Drupal CVS
Forgive me my shameless self-promotion, but I'd like to draw attention to my newly created Git-mirror of cvs.drupal.org Git ( http://git.or.cz/ ) is a great version control system that I use to keep my Drupal-sites up-to-date, so a complete mirroring of Drupals CVS with tags and branches and all is a great step forward - for me at any rate. I've made a longer blog post about it here: http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs The repository is here: http://git.lion47.com/cgi-bin/gitweb.cgi Kind regards, Mikkel Høgh <mikkel@hoegh.org>
On Tuesday, 19. February 2008, Mikkel Høgh wrote:
Forgive me my shameless self-promotion, but I'd like to draw attention to my newly created Git-mirror of cvs.drupal.org
Nice, makes for a good test case for the Version Control API Git backend :D Thanks, Jakob
Hi, This is great. I have a git mirror of the e-Commerce cvs and this looks great. I did try and make a drupal mirror but it would not import it because it was so big. It would be also nice if you can turn on blame which is like annotate. See what I have done at http://git.drupalecommerce.org Gordon. Mikkel Høgh wrote:
Forgive me my shameless self-promotion, but I'd like to draw attention to my newly created Git-mirror of cvs.drupal.org
Git ( http://git.or.cz/ ) is a great version control system that I use to keep my Drupal-sites up-to-date, so a complete mirroring of Drupals CVS with tags and branches and all is a great step forward - for me at any rate.
I've made a longer blog post about it here: http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs
The repository is here: http://git.lion47.com/cgi-bin/gitweb.cgi
Kind regards, Mikkel Høgh <mikkel@hoegh.org>
!DSPAM:1000,47baeae8295767450237654!
Hi Gordon, I have enabled "blame". I'm glad to see that Git is catching on around the Drupal community. I hope some day to be able to look back at CVS as only a bad memory ;) And yeah, it is big. It took hours to import it with git cvsimport, but amazingly, the whole repository only takes up 15MB, which is really impressive to me, since it includes the entire CVS repository will themes, images and code with a lot of changes these 8 years. That's like 2MB per year. I'm afraid that we won't be so lucky with the contributions repository, but if we ever were to switch to Git or something like it, it would be madness to continue to have all 1000+ modules in the same repository - it's maddening enough already ;) //mikl Gordon Heydon wrote:
Hi,
This is great. I have a git mirror of the e-Commerce cvs and this looks great.
I did try and make a drupal mirror but it would not import it because it was so big.
It would be also nice if you can turn on blame which is like annotate.
See what I have done at http://git.drupalecommerce.org
Gordon.
Mikkel Høgh wrote:
Forgive me my shameless self-promotion, but I'd like to draw attention to my newly created Git-mirror of cvs.drupal.org
Git ( http://git.or.cz/ ) is a great version control system that I use to keep my Drupal-sites up-to-date, so a complete mirroring of Drupals CVS with tags and branches and all is a great step forward - for me at any rate.
I've made a longer blog post about it here: http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs
The repository is here: http://git.lion47.com/cgi-bin/gitweb.cgi
Kind regards, Mikkel Høgh <mikkel@hoegh.org>
!DSPAM:1000,47baeae8295767450237654!
Hi, Mikkel Høgh wrote:
Hi Gordon,
I have enabled "blame". I'm glad to see that Git is catching on around the Drupal community. I hope some day to be able to look back at CVS as only a bad memory ;)
Yes that would be nice, but if something like git were to be adopted then we would still offer CVS as a entry level so people can easily commit stuff with having the ease of learning git.
And yeah, it is big. It took hours to import it with git cvsimport, but amazingly, the whole repository only takes up 15MB, which is really impressive to me, since it includes the entire CVS repository will themes, images and code with a lot of changes these 8 years. That's like 2MB per year.
That is so cool, I need to check this out more.
I'm afraid that we won't be so lucky with the contributions repository, but if we ever were to switch to Git or something like it, it would be madness to continue to have all 1000+ modules in the same repository - it's maddening enough already ;)
Yes I have been thinking about this, and I think that we would need to break each of the projects out into there own repositories, so they would be easier to maintain, and divide up the permissions. I really like git a lot, and I would be interested in collaborating on this with you. Gordon.
//mikl
Gordon Heydon wrote:
Hi,
This is great. I have a git mirror of the e-Commerce cvs and this looks great.
I did try and make a drupal mirror but it would not import it because it was so big.
It would be also nice if you can turn on blame which is like annotate.
See what I have done at http://git.drupalecommerce.org
Gordon.
Mikkel Høgh wrote:
Forgive me my shameless self-promotion, but I'd like to draw attention to my newly created Git-mirror of cvs.drupal.org
Git ( http://git.or.cz/ ) is a great version control system that I use to keep my Drupal-sites up-to-date, so a complete mirroring of Drupals CVS with tags and branches and all is a great step forward - for me at any rate.
I've made a longer blog post about it here: http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs
The repository is here: http://git.lion47.com/cgi-bin/gitweb.cgi
Kind regards, Mikkel Høgh <mikkel@hoegh.org>
!DSPAM:1000,47bd521f234551804284693!
Just to add my two cents worth... This concept is doubly important, not only in ridding the Drupal Community of the deprecated CVS on the level of source code versioning; but also because of its powerful distribution features: it is a _distributed_ version control system. As per http://git.or.cz/ Besides providing a version control system, the Git project provides a
generic low-level toolkit for tree history storage and directory content management.
Git gives each developer a local copy of the entire development history, and
changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch.
What I mean is, git has strong implications for helping with the eternal _build_ and development versioning problems now inherent in Drupal site-building: branching from production to development, then back into production... It it's good enough for Linux, it's good enough for Drupal :) Victor Kane http://awebfactory.com.ar On Thu, Feb 21, 2008 at 8:26 PM, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
Mikkel Høgh wrote:
Hi Gordon,
I have enabled "blame". I'm glad to see that Git is catching on around the Drupal community. I hope some day to be able to look back at CVS as only a bad memory ;)
Yes that would be nice, but if something like git were to be adopted then we would still offer CVS as a entry level so people can easily commit stuff with having the ease of learning git.
And yeah, it is big. It took hours to import it with git cvsimport, but amazingly, the whole repository only takes up 15MB, which is really impressive to me, since it includes the entire CVS repository will themes, images and code with a lot of changes these 8 years. That's like 2MB per year.
That is so cool, I need to check this out more.
I'm afraid that we won't be so lucky with the contributions repository, but if we ever were to switch to Git or something like it, it would be madness to continue to have all 1000+ modules in the same repository - it's maddening enough already ;)
Yes I have been thinking about this, and I think that we would need to break each of the projects out into there own repositories, so they would be easier to maintain, and divide up the permissions.
I really like git a lot, and I would be interested in collaborating on this with you.
Gordon.
//mikl
Gordon Heydon wrote:
Hi,
This is great. I have a git mirror of the e-Commerce cvs and this looks great.
I did try and make a drupal mirror but it would not import it because it was so big.
It would be also nice if you can turn on blame which is like annotate.
See what I have done at http://git.drupalecommerce.org
Gordon.
Mikkel Høgh wrote:
Forgive me my shameless self-promotion, but I'd like to draw attention to my newly created Git-mirror of cvs.drupal.org
Git ( http://git.or.cz/ ) is a great version control system that I use to keep my Drupal-sites up-to-date, so a complete mirroring of Drupals CVS with tags and branches and all is a great step forward - for me at any rate.
I've made a longer blog post about it here: http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs
The repository is here: http://git.lion47.com/cgi-bin/gitweb.cgi
Kind regards, Mikkel Høgh <mikkel@hoegh.org>
!DSPAM:1000,47bd521f234551804284693!
Just to add my two cents worth... This concept is doubly important, not only in ridding the Drupal Community of the deprecated CVS on the level of source code versioning; but also because of its powerful distribution features: it is a _distributed_ version control system.
However great git is, given the huge number of our contributors using Windows and on various levels of knowledge about RCS systems, anything without a proper Windows port and a Tortoise-alike interface has no chance. To my knowledge, current this means Mercurial: 2007-12-02: First public release (0.0.1) of TortoiseHg with binary installer. Since then there were three more releases -- quite an active project. There is a http://repo.or.cz/w/git-cheetah.git/ which says "This is an explorer extension in its infancy. Do not expect anything to work, unless you are fixing it." -- unless this becomes useable, git is out of question. We have a versioncontrol module (thanks to jpetso) and thanks to GHOP, students has written svn (ok this needed just finalizing), git and hg bridges for it. We all experiment with this or that DRCS, I am running bzr for core development, Gordon (and if memory serves, Ber too) was running darcs before and now Gordon runs git etc. Neither the GHOP project nor these experiments mean that "that Git is catching on around the Drupal community. I hope some day to be able to look back at CVS as only a bad memory". Do we want to change? I presume that the project-VCS API integration happens eventually so drupal.org is ready (this is quite a stretch). Well, after many years I am not so sure. Are the niceties of SVN over CVS are enough to make such a big change? What this buys us? Will the hard concepts of branching and tagging become easier for our contrib authors? I doubt. Can people learn any DRCS be it hg or git? With a DRCS you have the quite powerful concepts of developing here and there and then merging... I am quite unsure this will be too easy for our contributors. Drupal is quite a unique project here. We not just have thousands of contrib authors, among these are theme developers who have skills I can only envy but on the other hand, the RCS systems developed primarily for coder nerds are hard for them. I am not talking of translators here, I hope Drupal translation server will come online and remove them from the contrib repo. And also there are coders who are among the greatest contributors to Drupal, coding and again, any RCS concepts are not easy for them. Do not reply to this list unless you have very, very well thought out answers. I am experimenting with alternates for three years now and my stance is now "change? hmmmm not so sure" -- do not rush your answer. I do not want another iteration of "let's switch to foo RCS", we had this discussion too many times. Instead of switching, I would like to call out to the developer community -- how can we make it easier to use these systems? Can we offer a web upload for example for themers? FTP maybe, somehow? Kind regards, Karoly Negyesi
1. Thanks for an excellent background article. 2. see below On Fri, Feb 22, 2008 at 11:27 AM, Karoly Negyesi <karoly@negyesi.net> wrote:
Just to add my two cents worth... This concept is doubly important, not only in ridding the Drupal Community of the deprecated CVS on the level of source code versioning; but also because of its powerful distribution features: it is a _distributed_ version control system.
Do not reply to this list unless you have very, very well thought out answers. I am experimenting with alternates for three years now and my stance is now "change? hmmmm not so sure" -- do not rush your answer. I do not want another iteration of "let's switch to foo RCS", we had this discussion too many times.
We do want to avoid a repetition of past discussions, but we do need the freedom to discuss alternatives, since the capabilities of these tools has developed a lot recently.
Instead of switching, I would like to call out to the developer community -- how can we make it easier to use these systems? Can we offer a web upload for example for themers? FTP maybe, somehow?
Now, this brings to the fore ideas about having a simple front end solution for themers, new users, etc., a front end to an arbitrarily complex back end. Maybe that is what should be worked on, for the benefit of those folks. But the rest of it is to also search for solutions for site building and the eternal quest for separating content from configuration, problems in deployment, etc.
Kind regards,
Karoly Negyesi
Saludos, Victor Kane
On Feb 22, 2008, at 14:27 , Karoly Negyesi wrote:
However great git is, given the huge number of our contributors using Windows and on various levels of knowledge about RCS systems, anything without a proper Windows port and a Tortoise-alike interface has no chance. To my knowledge, current this means Mercurial: 2007-12-02: First public release (0.0.1) of TortoiseHg with binary installer. Since then there were three more releases -- quite an active project. There is a http://repo.or.cz/w/git-cheetah.git/ which says "This is an explorer extension in its infancy. Do not expect anything to work, unless you are fixing it." -- unless this becomes useable, git is out of question.
...
Do we want to change? I presume that the project-VCS API integration happens eventually so drupal.org is ready (this is quite a stretch). Well, after many years I am not so sure. Are the niceties of SVN over CVS are enough to make such a big change? What this buys us? Will the hard concepts of branching and tagging become easier for our contrib authors? I doubt.
At first, I found using CVS a hurdle. I managed, but I had to look up several of the commands every time. Until I discovered the usage of .bash_profile. Now I absolutely don't mind using CVS, since all ugly things are abstracted away (although several of these commands are Drupal-specific, but that doesn't matter to me, as I use SVN everywhere else). My point is: the biggest problem people have with CVS, is the usability aspect (actually the concepts, but it's usability improvements that should make the core concepts obvious). However, that can be overcome by using your shell effectively – any coder should know how to use a RCS and the shell. But that doesn't solve the other problem: themers generally don't know how to use a RCS in the first place. Changing to a different RCS won't fix any of these problems, at least not to the level where we need it. So I think a good candidate "solution" ("improvement" would be more accurate), would be to code our own CVS front-end, tied specifically to Drupal purposes. If written in C++/Qt, it would be possible to provide a cross-platform interface. Cross-platform is important to us: we want to support both Windows and Mac OS X (and perhaps more). This would probably be used by many coders too, not just themers. Does anybody think this is a good idea? Or perhaps it could not work? If so, for which reasons? So I fully agree with you, Karoly, changing the RCS won't fix any of the *real* issues we're currently having :) Wim Leers ~ http://wimleers.com/work
That's a great idea. It'd be fairly straightforward to make a simple drupal-specific frontend to CVS that cover the common-use cases. It'd even make coders lives easier as in my case, whenever I want to update my module I still have to look-up the documentation as I use other RCS systems then CVS. Kyle On Fri, Feb 22, 2008 at 10:11 AM, Wim Leers <work@wimleers.com> wrote:
On Feb 22, 2008, at 14:27 , Karoly Negyesi wrote:
However great git is, given the huge number of our contributors using Windows and on various levels of knowledge about RCS systems, anything without a proper Windows port and a Tortoise-alike interface has no chance. To my knowledge, current this means Mercurial: 2007-12-02: First public release (0.0.1) of TortoiseHg with binary installer. Since then there were three more releases -- quite an active project. There is a http://repo.or.cz/w/git-cheetah.git/ which says "This is an explorer extension in its infancy. Do not expect anything to work, unless you are fixing it." -- unless this becomes useable, git is out of question.
...
Do we want to change? I presume that the project-VCS API integration happens eventually so drupal.org is ready (this is quite a stretch). Well, after many years I am not so sure. Are the niceties of SVN over CVS are enough to make such a big change? What this buys us? Will the hard concepts of branching and tagging become easier for our contrib authors? I doubt.
At first, I found using CVS a hurdle. I managed, but I had to look up several of the commands every time. Until I discovered the usage of .bash_profile. Now I absolutely don't mind using CVS, since all ugly things are abstracted away (although several of these commands are Drupal-specific, but that doesn't matter to me, as I use SVN everywhere else).
My point is: the biggest problem people have with CVS, is the usability aspect (actually the concepts, but it's usability improvements that should make the core concepts obvious). However, that can be overcome by using your shell effectively – any coder should know how to use a RCS and the shell. But that doesn't solve the other problem: themers generally don't know how to use a RCS in the first place. Changing to a different RCS won't fix any of these problems, at least not to the level where we need it.
So I think a good candidate "solution" ("improvement" would be more accurate), would be to code our own CVS front-end, tied specifically to Drupal purposes. If written in C++/Qt, it would be possible to provide a cross-platform interface. Cross-platform is important to us: we want to support both Windows and Mac OS X (and perhaps more). This would probably be used by many coders too, not just themers. Does anybody think this is a good idea? Or perhaps it could not work? If so, for which reasons?
So I fully agree with you, Karoly, changing the RCS won't fix any of the *real* issues we're currently having :)
Wim Leers ~ http://wimleers.com/work
-- Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog
On Fri, Feb 22, 2008 at 11:30:34PM -0600, Scott McLewin wrote:
How about a switch to Microsoft's Team Foundation Server?
<ducks/>
Karoly Negyesi wrote:
Do not reply to this list unless you have very, very well thought out answers.
RCS for the win. But seriously, I was the last person who brought this up and dww was kind enough to respond in some length in this issue: http://drupal.org/node/187019 This is a no-go for social reasons at the moment, but having a git mirror up is pretty cool. If running it ever becomes a hardship for you, let me know. -- Narayan Newton Database Administrator OSU Open Source Lab GA Member Drupal Association
On Sat, Feb 23, 2008 at 9:21 PM, Narayan Newton <nnewton@osuosl.org> wrote:
This is a no-go for social reasons at the moment, but having a git mirror up is pretty cool. If running it ever becomes a hardship for you, let me know.
I take it the git mirror can only be used for pulling patches/changesets in from other git repositories, and not for pushing patches/changesets to the main Drupal tree (i.e. CVS HEAD on drupal.org)? -- Dries Buytaert :: http://buytaert.net/
hi, Dries Buytaert wrote:
On Sat, Feb 23, 2008 at 9:21 PM, Narayan Newton <nnewton@osuosl.org> wrote:
This is a no-go for social reasons at the moment, but having a git mirror up is pretty cool. If running it ever becomes a hardship for you, let me know.
I take it the git mirror can only be used for pulling patches/changesets in from other git repositories, and not for pushing patches/changesets to the main Drupal tree (i.e. CVS HEAD on drupal.org)?
Yes it is only for pulling. If Drupal was to use git it would work much the same, but when you would committed patches they would be marked as committed by you, but the patch author would be the person who wrote it. Gordon.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Narayan Newton schrieb:
On Fri, Feb 22, 2008 at 11:30:34PM -0600, Scott McLewin wrote:
How about a switch to Microsoft's Team Foundation Server?
<ducks/>
Karoly Negyesi wrote:
Do not reply to this list unless you have very, very well thought out answers.
RCS for the win.
But seriously, I was the last person who brought this up and dww was kind enough to respond in some length in this issue: http://drupal.org/node/187019
This is a no-go for social reasons at the moment, but having a git mirror up is pretty cool. If running it ever becomes a hardship for you, let me know.
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwoiffg6TFvELooQRAmajAKCsj1NqzVhEtaMYVDoLGvyHyHSXaQCfUZqj W+nZOu3zEhxyDb2ONlS2Fwc= =3NjZ -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons.
This sounds like an excellent idea! The only problem is having to maintain two seperate version control systems at the same time. On a related point: if this works for core, would it not make sense to allow contrib maintainers the option to use Git instead of CVS? Make Git optional and contrib maintainers can move over at their own speed. If/when a Windows GUI client becomes available for example. It would also be interesting to see how many people stick with CVS, if nearly everyone switches their modules/themes to Git, CVS could be deprecated pretty quickly. Just throwing some ideas around. Sorry if this has all been said before. :) Kind Regards, Liam McDermott.
Quoting Liam McDermott <liam@intermedia-online.com>:
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons.
This sounds like an excellent idea! The only problem is having to maintain two seperate version control systems at the same time. On a related point: if this works for core, would it not make sense to allow contrib maintainers the option to use Git instead of CVS?
Make Git optional and contrib maintainers can move over at their own speed. If/when a Windows GUI client becomes available for example. It would also be interesting to see how many people stick with CVS, if nearly everyone switches their modules/themes to Git, CVS could be deprecated pretty quickly.
Just throwing some ideas around. Sorry if this has all been said before. :)
Nice idea. Now all that is left is the work to help Derek with making the transition for the project module. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Monday, 25. February 2008, Earnie Boyd wrote:
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons. [snip]
Nice idea. Now all that is left is the work to help Derek with making the transition for the project module.
And of course, there's a list of tasks for anyone who wants to push this forward: http://groups.drupal.org/node/8102 See you in the issue queue, cheers, Jakob
On Mon, 25 Feb 2008 15:44:56 -0500, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Liam McDermott <liam@intermedia-online.com>:
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons.
This sounds like an excellent idea! The only problem is having to maintain two seperate version control systems at the same time. On a related point: if this works for core, would it not make sense to allow contrib maintainers the option to use Git instead of CVS?
Make Git optional and contrib maintainers can move over at their own speed. If/when a Windows GUI client becomes available for example. It would also be interesting to see how many people stick with CVS, if nearly everyone switches their modules/themes to Git, CVS could be deprecated pretty quickly.
Just throwing some ideas around. Sorry if this has all been said before. :)
Nice idea. Now all that is left is the work to help Derek with making the transition for the project module.
Except for those people who do checkout anonymously from core for various reasons and don't want to have to deal with yet another RCS with completely different semantics... *raises hand* --Larry Garfield
On Tuesday, 26. February 2008, Larry Garfield wrote:
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons. [snip]
Except for those people who do checkout anonymously from core for various reasons and don't want to have to deal with yet another RCS with completely different semantics...
Arguably, this is a prime example of where the git-cvs bridge would actually help instead of complicating stuff. (Can be set up in a backwards-compatible way, no documentation changes needed in order to keep working, doesn't complicate the process for contrib authors.) Given that core has probably the largest number of patches that were not authored by the committer, and is generally developed in a more Linux-style fashion (few gatekeepers, many branches and patches from outside - as opposed to contrib), I tend to like this proposal and think that core is probably the place where distributed version control would be most helpful. --Jakob Petsovits
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Garfield schrieb:
On Mon, 25 Feb 2008 15:44:56 -0500, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Liam McDermott <liam@intermedia-online.com>:
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons. This sounds like an excellent idea! The only problem is having to maintain two seperate version control systems at the same time. On a related point: if this works for core, would it not make sense to allow contrib maintainers the option to use Git instead of CVS?
Make Git optional and contrib maintainers can move over at their own speed. If/when a Windows GUI client becomes available for example. It would also be interesting to see how many people stick with CVS, if nearly everyone switches their modules/themes to Git, CVS could be deprecated pretty quickly.
Just throwing some ideas around. Sorry if this has all been said before. :) Nice idea. Now all that is left is the work to help Derek with making the transition for the project module.
Except for those people who do checkout anonymously from core for various reasons and don't want to have to deal with yet another RCS with completely different semantics...
*raises hand*
Well, there could be a read-only cvs (or svn) mirror of core... :p Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw+bofg6TFvELooQRAgfzAJ9P1BrZZ0VcH2eOcvgmlyKK9IYUDgCcCKPv 5snd4nrXsSAkO5X+QivCc0E= =trDu -----END PGP SIGNATURE-----
On Tue, Feb 26, 2008 at 11:16:08AM +0100, Gerhard Killesreiter wrote:
Larry Garfield schrieb:
On Mon, 25 Feb 2008 15:44:56 -0500, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Liam McDermott <liam@intermedia-online.com>:
Gerhard Killesreiter wrote:
What we coud do (as long as the relevant backend for the project module exists) is to move core development to git. There we are free of social reasons. This sounds like an excellent idea! The only problem is having to maintain two seperate version control systems at the same time. On a related point: if this works for core, would it not make sense to allow contrib maintainers the option to use Git instead of CVS?
Make Git optional and contrib maintainers can move over at their own speed. If/when a Windows GUI client becomes available for example. It would also be interesting to see how many people stick with CVS, if nearly everyone switches their modules/themes to Git, CVS could be deprecated pretty quickly.
Just throwing some ideas around. Sorry if this has all been said before. :) Nice idea. Now all that is left is the work to help Derek with making the transition for the project module.
Except for those people who do checkout anonymously from core for various reasons and don't want to have to deal with yet another RCS with completely different semantics...
*raises hand*
Well, there could be a read-only cvs (or svn) mirror of core... :p
Cheers, Gerhard
Ya, we could use the git-cvsserver to still have anon-cvs access for core. -- Narayan Newton Database Administrator OSU Open Source Lab GA Member Drupal Association
Well, there could be a read-only cvs (or svn) mirror of core... :p Ya, we could use the git-cvsserver to still have anon-cvs access for core.
And then we could accept patches against that still so that small patches need no separate git branch and still everyone can write a patch w/o learning git but folks like me with their 200K patches can just submit a repo URL. I like this.
Hi, The thing that I think that is needed is better tracking of code authors. With GIT (and other systems) is that you can see who who the patch. If you take a look at the Drupal 7 branch, it indicates that the author is Dries, which is not true. Dries is the committer. Using git we can see who the author and the committer is, as well as patches can be signed by anyone who has handled the patch, eg a chain of evidence. Lastly the biggest and best feature of git is the branch handling, and being able to move patches from 1 branch to another is very painless. With e-Commerce having multiple stable versions, this feature has saved so much time. Also with e-Commerce I think that I need to move to a system where I can track all the authores of the code since e-Commerce is dealing directly wth people's money. Gordon. Victor Kane wrote:
Just to add my two cents worth... This concept is doubly important, not only in ridding the Drupal Community of the deprecated CVS on the level of source code versioning; but also because of its powerful distribution features: it is a _distributed_ version control system.
As per http://git.or.cz/
Besides providing a version control system, the Git project provides a generic low-level toolkit for tree history storage and directory content management.
Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch.
What I mean is, git has strong implications for helping with the eternal _build_ and development versioning problems now inherent in Drupal site-building: branching from production to development, then back into production...
It it's good enough for Linux, it's good enough for Drupal :)
Victor Kane http://awebfactory.com.ar
On Thu, Feb 21, 2008 at 8:26 PM, Gordon Heydon <gordon@heydon.com.au <mailto:gordon@heydon.com.au>> wrote:
Hi,
Mikkel Høgh wrote: > Hi Gordon, > > I have enabled "blame". > I'm glad to see that Git is catching on around the Drupal community. I > hope some day to be able to look back at CVS as only a bad memory ;)
Yes that would be nice, but if something like git were to be adopted then we would still offer CVS as a entry level so people can easily commit stuff with having the ease of learning git.
> And yeah, it is big. It took hours to import it with git cvsimport, but > amazingly, the whole repository only takes up 15MB, which is really > impressive to me, since it includes the entire CVS repository will > themes, images and code with a lot of changes these 8 years. That's like > 2MB per year.
That is so cool, I need to check this out more.
> I'm afraid that we won't be so lucky with the contributions repository, > but if we ever were to switch to Git or something like it, it would be > madness to continue to have all 1000+ modules in the same repository - > it's maddening enough already ;)
Yes I have been thinking about this, and I think that we would need to break each of the projects out into there own repositories, so they would be easier to maintain, and divide up the permissions.
I really like git a lot, and I would be interested in collaborating on this with you.
Gordon.
> //mikl > > Gordon Heydon wrote: >> Hi, >> >> This is great. I have a git mirror of the e-Commerce cvs and this >> looks great. >> >> I did try and make a drupal mirror but it would not import it because >> it was so big. >> >> It would be also nice if you can turn on blame which is like annotate. >> >> See what I have done at http://git.drupalecommerce.org >> >> Gordon. >> >> Mikkel Høgh wrote: >>> Forgive me my shameless self-promotion, but I'd like to draw >>> attention to my newly created Git-mirror of cvs.drupal.org <http://cvs.drupal.org> >>> >>> Git ( http://git.or.cz/ ) is a great version control system that I >>> use to keep my Drupal-sites up-to-date, so a complete mirroring of >>> Drupals CVS with tags and branches and all is a great step forward - >>> for me at any rate. >>> >>> I've made a longer blog post about it here: >>> http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs >>> >>> The repository is here: >>> http://git.lion47.com/cgi-bin/gitweb.cgi >>> >>> Kind regards, >>> Mikkel Høgh <mikkel@hoegh.org <mailto:mikkel@hoegh.org>> >>> >>> >>> > > >
!DSPAM:1000,47be9bdd44685696618876!
I know that this is a controversial issue, but I feel I might have come across harsher than I intended. I agree with Karoly that Git (or bzr or Mercurial or...) is not the answer to all our problems. Especially the lack of good, stable Windows/Mac GUI clients for all the aforementioned systems is a big showstopper. TortoiseHg is out, but still very much beta. I think the keyword here is _eventually_. I hope that we can all agree that CVS is past its prime. Its many predecessors hold many advantages over it. Many new features that CVS will probably never get. So while we're not in a position to switch to something else right now or this year, it would still be wise to consider the future. I could rant endlessly about why distributed SCM is great and boosts productivity, makes it easier to try out crazy ideas. Makes branching and merging easier and so on, but I suppose you all know this. So all I'm saying is that we ought to consider switching to something else at some point in the future, because CVS isn't that great now and is not likely to get better. Kind regards, Mikkel Høgh Gordon Heydon wrote:
Hi,
The thing that I think that is needed is better tracking of code authors. With GIT (and other systems) is that you can see who who the patch.
If you take a look at the Drupal 7 branch, it indicates that the author is Dries, which is not true. Dries is the committer. Using git we can see who the author and the committer is, as well as patches can be signed by anyone who has handled the patch, eg a chain of evidence.
Lastly the biggest and best feature of git is the branch handling, and being able to move patches from 1 branch to another is very painless. With e-Commerce having multiple stable versions, this feature has saved so much time.
Also with e-Commerce I think that I need to move to a system where I can track all the authores of the code since e-Commerce is dealing directly wth people's money.
Gordon.
Victor Kane wrote:
Just to add my two cents worth... This concept is doubly important, not only in ridding the Drupal Community of the deprecated CVS on the level of source code versioning; but also because of its powerful distribution features: it is a _distributed_ version control system.
As per http://git.or.cz/
Besides providing a version control system, the Git project provides a generic low-level toolkit for tree history storage and directory content management.
Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch.
What I mean is, git has strong implications for helping with the eternal _build_ and development versioning problems now inherent in Drupal site-building: branching from production to development, then back into production...
It it's good enough for Linux, it's good enough for Drupal :)
Victor Kane http://awebfactory.com.ar
On Thu, Feb 21, 2008 at 8:26 PM, Gordon Heydon <gordon@heydon.com.au <mailto:gordon@heydon.com.au>> wrote:
Hi,
Mikkel Høgh wrote: > Hi Gordon, > > I have enabled "blame". > I'm glad to see that Git is catching on around the Drupal community. I > hope some day to be able to look back at CVS as only a bad memory ;)
Yes that would be nice, but if something like git were to be adopted then we would still offer CVS as a entry level so people can easily commit stuff with having the ease of learning git.
> And yeah, it is big. It took hours to import it with git cvsimport, but > amazingly, the whole repository only takes up 15MB, which is really > impressive to me, since it includes the entire CVS repository will > themes, images and code with a lot of changes these 8 years. That's like > 2MB per year.
That is so cool, I need to check this out more.
> I'm afraid that we won't be so lucky with the contributions repository, > but if we ever were to switch to Git or something like it, it would be > madness to continue to have all 1000+ modules in the same repository - > it's maddening enough already ;)
Yes I have been thinking about this, and I think that we would need to break each of the projects out into there own repositories, so they would be easier to maintain, and divide up the permissions.
I really like git a lot, and I would be interested in collaborating on this with you.
Gordon.
> //mikl > > Gordon Heydon wrote: >> Hi, >> >> This is great. I have a git mirror of the e-Commerce cvs and this >> looks great. >> >> I did try and make a drupal mirror but it would not import it because >> it was so big. >> >> It would be also nice if you can turn on blame which is like annotate. >> >> See what I have done at http://git.drupalecommerce.org >> >> Gordon. >> >> Mikkel Høgh wrote: >>> Forgive me my shameless self-promotion, but I'd like to draw >>> attention to my newly created Git-mirror of cvs.drupal.org <http://cvs.drupal.org> >>> >>> Git ( http://git.or.cz/ ) is a great version control system that I >>> use to keep my Drupal-sites up-to-date, so a complete mirroring of >>> Drupals CVS with tags and branches and all is a great step forward - >>> for me at any rate. >>> >>> I've made a longer blog post about it here: >>> http://mikkel.hoegh.org/blog/2008/a_git_mirror_for_drupal_cvs >>> >>> The repository is here: >>> http://git.lion47.com/cgi-bin/gitweb.cgi >>> >>> Kind regards, >>> Mikkel Høgh <mikkel@hoegh.org <mailto:mikkel@hoegh.org>> >>> >>> >>> > > >
!DSPAM:1000,47be9bdd44685696618876!
I am quoting this mail almost in full because it is so typical: "CVS sucks! Let's switch!" This is so irrevelant -- everyone on this list is aware of the shortcomings of CVS without taking Drupal in regard -- most troublesome is the lack of version controlled directories and renames. But the problem is that we NEED to take Drupal in regard. And then the questions to answer are: Why do we want to switch? To answer that, list the current problems of our contrib authors. Go out and do the research, ask them. How will git or Mercurial help solving those? E.g. people who do not get at all what a branch a tag will have less problem with this when facing all the possibilites, say, git offer? Think of human issues here. Think someone who needs all her wits to put together a module or the template.php of a theme and then needs to fight the monster an RCS is. Can you explain the multiple heads in Mercurial to her in a very simple way? Let me doubt.
I agree with Karoly that Git (or bzr or Mercurial or...) is not the answer to all our problems. Especially the lack of good, stable Windows/Mac GUI clients for all the aforementioned systems is a big showstopper. TortoiseHg is out, but still very much beta.
I think the keyword here is _eventually_. I hope that we can all agree that CVS is past its prime. Its many predecessors hold many advantages over it. Many new features that CVS will probably never get. So while we're not in a position to switch to something else right now or this year, it would still be wise to consider the future.
I could rant endlessly about why distributed SCM is great and boosts productivity, makes it easier to try out crazy ideas. Makes branching and merging easier and so on, but I suppose you all know this.
So all I'm saying is that we ought to consider switching to something else at some point in the future, because CVS isn't that great now and is not likely to get better.
You seem to be under the assumption that we would do everything the same way as we do today if we switched to another VCS. You talk about solving real problems: What if publishing my new module to Drupal's servers was no more complicated than "bzr push sftp://bzr.drupal.org/~mikl/asdf-module". The Launchpad.net guys have done this. It's real and working. I've used it myself. Instead of using multiple heads and that kind of nastiness, you could just use bzr-style branches. A different physical folder for each branch. That's something almost anyone should be able to comprehend. asdf-module-d5 is for drupal 5 and asdf-module-d6 is for Drupal 6. Simple. Thanks to new algorithms, merging is a breeze (3-way merging can still require human judgment, but is still a lot easier than it was in the old days), so if I wanted to try out Crazy Idea X on Drupal core, I'd just create my own branch/folder, drupal-cix and muck about with the code, committing regularly, without disturbing anyone else. And if some of the stuff I did (but maybe not all of it) was usable, one of the core devs might merge some of my changes. So if we were to switch (and I'm not saying we have to, but I still think it would be a benefit to do so at some point in the future when we have a Windows GUI client and other requirements sorted out), we should be looking to make our structure simpler, not more complex. Karoly Negyesi wrote:
I am quoting this mail almost in full because it is so typical: "CVS sucks! Let's switch!" This is so irrevelant -- everyone on this list is aware of the shortcomings of CVS without taking Drupal in regard -- most troublesome is the lack of version controlled directories and renames. But the problem is that we NEED to take Drupal in regard. And then the questions to answer are: Why do we want to switch? To answer that, list the current problems of our contrib authors. Go out and do the research, ask them. How will git or Mercurial help solving those? E.g. people who do not get at all what a branch a tag will have less problem with this when facing all the possibilites, say, git offer? Think of human issues here. Think someone who needs all her wits to put together a module or the template.php of a theme and then needs to fight the monster an RCS is. Can you explain the multiple heads in Mercurial to her in a very simple way? Let me doubt.
I agree with Karoly that Git (or bzr or Mercurial or...) is not the answer to all our problems. Especially the lack of good, stable Windows/Mac GUI clients for all the aforementioned systems is a big showstopper. TortoiseHg is out, but still very much beta.
I think the keyword here is _eventually_. I hope that we can all agree that CVS is past its prime. Its many predecessors hold many advantages over it. Many new features that CVS will probably never get. So while we're not in a position to switch to something else right now or this year, it would still be wise to consider the future.
I could rant endlessly about why distributed SCM is great and boosts productivity, makes it easier to try out crazy ideas. Makes branching and merging easier and so on, but I suppose you all know this.
So all I'm saying is that we ought to consider switching to something else at some point in the future, because CVS isn't that great now and is not likely to get better.
Quoting Mikkel Høgh <mikkel@hoegh.org>:
So if we were to switch (and I'm not saying we have to, but I still think it would be a benefit to do so at some point in the future when we have a Windows GUI client and other requirements sorted out), we should be looking to make our structure simpler, not more complex.
BTW, Windows is supported by GIT developers via Cygwin or MSYS. The nice windowy GUI idea would be for those who are without a CLUI. Come on, even windows has a command line terminal. Yes, I'm a dinosaur but we're talking developers here. Surely all developers know how to type on a CLI. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Cygwin as a tool is sub-optimal even as a command line tool for Windows. A Unix port of tools used only within an emulated environment does not a supported platform make. Oh, the new command line for windows is PowerShell. Steven Peck On Sat, Feb 23, 2008 at 12:08 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Mikkel Høgh <mikkel@hoegh.org>:
So if we were to switch (and I'm not saying we have to, but I still think it would be a benefit to do so at some point in the future when we have a Windows GUI client and other requirements sorted out), we should be looking to make our structure simpler, not more complex.
BTW, Windows is supported by GIT developers via Cygwin or MSYS. The nice windowy GUI idea would be for those who are without a CLUI. Come on, even windows has a command line terminal. Yes, I'm a dinosaur but we're talking developers here. Surely all developers know how to type on a CLI.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Steven Peck <sepeck@gmail.com>:
Cygwin as a tool is sub-optimal even as a command line tool for Windows. A Unix port of tools used only within an emulated environment does not a supported platform make.
I think 10's of 1000's would argue with you. Since March 2004 there have been ~700,000+/- downloads of MSYS-1.0.10.exe alone.
Oh, the new command line for windows is PowerShell.
I try to stay away from the windows CLI preferring bash instead. As for GIT using Cygwin or MSYS they can write a shell command once and not have to port it to CMD .bat files so that it supports UNIX and WINDOWS at the same time. Less overhead in interoperability is the biggest benefits of Cygwin and MSYS even though it may be slightly sub-optimal. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
You display the very reason why it is sub-optimal for Windows. It is a Unix tool. It is a tool for people working in Unix land to use if they happen to be using a Windows OS. Does it work? Yes. Is it a Windows based tool? No. The multiple learning curve of Unix shell environment on top of a new RCS system including the overhead of installing yet more software on your system and the attendant issues of that learning curve would be a more then slight significant barrier to adoption. My comment wasn't about what an uber elite experienced unix admin / developer could do. It was about the fact that cygwin tools do not a windows port make. Steven -powershell doesn't use bat files On Sun, Feb 24, 2008 at 8:41 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Steven Peck <sepeck@gmail.com>:
Cygwin as a tool is sub-optimal even as a command line tool for Windows. A Unix port of tools used only within an emulated environment does not a supported platform make.
I think 10's of 1000's would argue with you. Since March 2004 there have been ~700,000+/- downloads of MSYS-1.0.10.exe alone.
Oh, the new command line for windows is PowerShell.
I try to stay away from the windows CLI preferring bash instead. As for GIT using Cygwin or MSYS they can write a shell command once and not have to port it to CMD .bat files so that it supports UNIX and WINDOWS at the same time. Less overhead in interoperability is the biggest benefits of Cygwin and MSYS even though it may be slightly sub-optimal.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Hi, Earnie Boyd wrote:
Quoting Mikkel Høgh <mikkel@hoegh.org>:
So if we were to switch (and I'm not saying we have to, but I still think it would be a benefit to do so at some point in the future when we have a Windows GUI client and other requirements sorted out), we should be looking to make our structure simpler, not more complex.
BTW, Windows is supported by GIT developers via Cygwin or MSYS. The nice windowy GUI idea would be for those who are without a CLUI. Come on, even windows has a command line terminal. Yes, I'm a dinosaur but we're talking developers here. Surely all developers know how to type on a CLI.
Well GIT does have a CVS server so all the GUI CVS tools can still be used. So people can start with CVS, and the later scale up the git command line and tcl gui Gordon.
On Sunday, 24. February 2008, Gordon Heydon wrote:
Hi,
Earnie Boyd wrote:
BTW, Windows is supported by GIT developers via Cygwin or MSYS. The nice windowy GUI idea would be for those who are without a CLUI. Come on, even windows has a command line terminal. Yes, I'm a dinosaur but we're talking developers here. Surely all developers know how to type on a CLI.
Well GIT does have a CVS server so all the GUI CVS tools can still be used.
So people can start with CVS, and the later scale up the git command line and tcl gui
Er, no. That's pure poison for documentation, understanding and collaboration. Not an option. If we're ever going to do a switch, it needs to be definitive - one single standard for everyone, and especially no paradigm change for newbies who want to use slightly more functionality than they did initially. (We could still provide VCS adaptors, but only as footnote and for those people who actually know what they're doing.) Jakob.
participants (15)
-
Dries Buytaert -
Earnie Boyd -
Gerhard Killesreiter -
Gordon Heydon -
Jakob Petsovits -
Karoly Negyesi -
Kyle Mathews -
Larry Garfield -
Liam McDermott -
Mikkel Høgh -
Narayan Newton -
Scott McLewin -
Steven Peck -
Victor Kane -
Wim Leers