-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You guys know we could so rock with subversion / drupal integration. right ? http://pecl.php.net/package/svn http://php5.akbkhome.com:81/svn.php - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDecAhgegMqdGlkasRAqTQAJwNUGQBkonY5onX1zgl4zC0V07oPwCguWA7 kXo5tVM5Cfu2ymHcgRHb3c0= =tAlz -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
You guys know we could so rock with subversion / drupal integration. right ?
http://pecl.php.net/package/svn http://php5.akbkhome.com:81/svn.php
The one and only issue I have with svn is that it does not have a usefull equivalent to the -p flag. I know there is a langthy equivalent for this, but this is not about patches tat I create but abotu patches that I receive and need to review. Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 1:06 PM, Gerhard Killesreiter wrote:
The one and only issue I have with svn is that it does not have a usefull equivalent to the -p flag. I know there is a langthy equivalent for this, but this is not about patches tat I create but abotu patches that I receive and need to review.
And it's been discussed to death and there's very good reason for applying patches that have been uploaded to the latest source, and then flagging ones that don't apply anymore and during this process we can re-create the patch in the correct way, and probably even run the code style script on them. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDecQ6gegMqdGlkasRAuuEAKCw7TXdgDmA5JyfMP2EiHcy6U3yawCgp4bt AOZKW4qgpSqHtLqzHYKUIZs= =3c18 -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15 Nov 2005, at 1:06 PM, Gerhard Killesreiter wrote:
The one and only issue I have with svn is that it does not have a usefull equivalent to the -p flag. I know there is a langthy equivalent for this, but this is not about patches tat I create but abotu patches that I receive and need to review.
And it's been discussed to death and there's very good reason for applying patches that have been uploaded to the latest source, and then flagging ones that don't apply anymore
and during this process we can re-create the patch in the correct way, and probably even run the code style script on them.
Yeah, we have been discussing this in the bus in Brussels. I don't see anybody coding this. Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 1:31 PM, Gerhard Killesreiter wrote:
Yeah, we have been discussing this in the bus in Brussels. I don't see anybody coding this. maybe because we haven't officially decided to move to svn yet.
me, and probably darix, wouldn't mind coding this, but we refuse to do so for cvs. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeckngegMqdGlkasRAm7aAJ9VaHW2ttwnPItftQYM+Nj6ajb3dQCeKryl YjORaQu1C795AYZReM9Fing= =dj3i -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15 Nov 2005, at 1:31 PM, Gerhard Killesreiter wrote:
Yeah, we have been discussing this in the bus in Brussels. I don't see anybody coding this.
maybe because we haven't officially decided to move to svn yet.
me, and probably darix, wouldn't mind coding this, but we refuse to do so for cvs.
Dries has said several times that he would be willing to move to svn as soon as the inrastructure (read: the code that integrates it) is there. That is about as official as it can get. Cheers, Gerhard
On Nov 15, 2005, at 3:19 AM, Adrian Rossouw wrote:
agging ones that don't apply anymore and during this process we can re-create the patch in the correct way, and probably even run the code style script on them.
It's hard to maintain a distribution, CivicSpace, between CVS and SVN. It's very hard for CSS developers to understand the complex commands of CVS. If anybody wants to code this please get in touch and I'll support it so we can move to SVN. Kieran
If anybody wants to code this please get in touch and I'll support it so we can move to SVN.
and if you do, feel free to just commit on top of the current svn.module. i built that out of need when few php based svn repos browsers were available. -moshe
Just an FYI, we recently decided at Flock not to go with SVN for our browser work but to instead use Mercurial (http://www.selenic.com/mercurial/wiki/index.cgi). Here are the reasons: Up sides: 1. distributed source model local versioning and ability to merge with other repositories 2. native binary support no stupid corrupt image files from forgetting to tag things, better performance 3. 3 way merge better merging logic for changes 4. native client-server concept better network performance 5. good performance on all platforms 6. simple clear architecture this is as opposed to svk, or CVS. I don't see it quite as clean as svn, where you can just imagine everything as a file sitting in a path 7. Has concept of both versions and change-sets nicer ways to think about changes Down Sides 1. mediocre windows support seems to work on windows, but the dev team does not have a full-time windows user, and there are more "minor" bugs on the windows version than UN*X versions (double warning messages, fewer command-line shortcuts) 2. rename support is not yet there this is in dev tree 3. medium disk space usage 340MB in CVS -> 700MB in HG 4. Not much integration with existing software There is no bug/project tracking system integrations, or very many web front ends to it, though the one it has is pretty good 5. mediocre branching branching is no worse than CVS, but not really much better, not as nice as svn/svk 6. still a bit immature but pretty well documented, this is a very active developing project Other things we evaluated: svn: is no because of poor performance on large projects especially on windows svk: is no because it is written in perl and that is not liked by some developers cvs: is no because it is old and there are several better options monotone: is no because it doesn't have real version numbers, and a very complicated data model clearcase: is no because it is obscenely expensive, and doesn't have a detached working mode, and is super complicated, and proprietary perforce: is no because it doesn't have a good concept of detached working and is proprietary git: is no because it doesn't work on windows and has a very specific work flow in mind arch: honestly haven't looked at that much, has a complicated model for versions. So we're going to use SVN for managing our website and Drupal on our end, but for browser development, we're using something other than SVN. Just thought you guys might like another (poosibly OT) opinion. Chris On 11/15/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
If anybody wants to code this please get in touch and I'll support it so we can move to SVN.
and if you do, feel free to just commit on top of the current svn.module. i built that out of need when few php based svn repos browsers were available.
-moshe
It took a while, but I finally found the License. It seems it is GPL, which gets a thumbs up from me. :) That said, isn't it best to simply stay with a devil you know vs. one you don't? Trae On Tue, 2005-11-15 at 18:07 -0800, Chris Messina wrote:
Just an FYI, we recently decided at Flock not to go with SVN for our browser work but to instead use Mercurial (http://www.selenic.com/mercurial/wiki/index.cgi). Here are the reasons:
Up sides:
1. distributed source model local versioning and ability to merge with other repositories 2. native binary support no stupid corrupt image files from forgetting to tag things, better performance 3. 3 way merge better merging logic for changes 4. native client-server concept better network performance 5. good performance on all platforms 6. simple clear architecture this is as opposed to svk, or CVS. I don't see it quite as clean as svn, where you can just imagine everything as a file sitting in a path 7. Has concept of both versions and change-sets nicer ways to think about changes
Down Sides
1. mediocre windows support seems to work on windows, but the dev team does not have a full-time windows user, and there are more "minor" bugs on the windows version than UN*X versions (double warning messages, fewer command-line shortcuts) 2. rename support is not yet there this is in dev tree 3. medium disk space usage 340MB in CVS -> 700MB in HG 4. Not much integration with existing software There is no bug/project tracking system integrations, or very many web front ends to it, though the one it has is pretty good 5. mediocre branching branching is no worse than CVS, but not really much better, not as nice as svn/svk 6. still a bit immature but pretty well documented, this is a very active developing project
Other things we evaluated:
svn: is no because of poor performance on large projects especially on windows svk: is no because it is written in perl and that is not liked by some developers cvs: is no because it is old and there are several better options monotone: is no because it doesn't have real version numbers, and a very complicated data model clearcase: is no because it is obscenely expensive, and doesn't have a detached working mode, and is super complicated, and proprietary perforce: is no because it doesn't have a good concept of detached working and is proprietary git: is no because it doesn't work on windows and has a very specific work flow in mind arch: honestly haven't looked at that much, has a complicated model for versions.
So we're going to use SVN for managing our website and Drupal on our end, but for browser development, we're using something other than SVN.
Just thought you guys might like another (poosibly OT) opinion.
Chris
On 11/15/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
If anybody wants to code this please get in touch and I'll support it so we can move to SVN.
and if you do, feel free to just commit on top of the current svn.module. i built that out of need when few php based svn repos browsers were available.
-moshe
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
On Wed, 16 Nov 2005 03:07:55 +0100, Chris Messina <chris.messina@gmail.com> wrote:
Just an FYI, we recently decided at Flock not to go with SVN for our browser work but to instead use Mercurial
If there is no Windows GUI, we can't use it. Case closed. I wanted to write that if this statement would not stand I'd vote on bzr. But... http://meld.sourceforge.net/ since november 9 Meld has bzr support! Yay! And there is GTK+ on Windows: http://www.gimp.org/~tml/gimp/win32/ and there is PyGTK on Windows: http://www.pcpm.ucl.ac.be/~gustin/win32_ports/ so let me ask very happily this from the list: What do you think of bzr (aka bazaar-ng)? I say, get prepared now, and launch in sync with bzr 2.0. Regards NK Ps. For those with Google allergies: http://bazaar.canonical.com
On 11/15/05 9:07 PM, Chris Messina wrote:
So we're going to use SVN for managing our website and Drupal on our end, but for browser development, we're using something other than SVN.
okaaay.. so all those of us developing browsers should have a look at mercurial. i'm picking on you, but we're talking about a much larger development community than flock's (where it's mostly flock inc. + a few EFA's). Things like good support on all platforms, and integrations in popular IDE's etc are pretty crucial to adoption. I'm not particularly wedded to any SCM system... but right now, I think there are bigger things to worry about in the community than version control systems. I like SVN because it fixes some of CVS's braindeadedness without working too much differently. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Fair enough. It just seemed like it might be interesting to see another perspective, though I grant you our needs are notably different than Drupal's. Chris On 11/15/05, James Walker <walkah@walkah.net> wrote:
On 11/15/05 9:07 PM, Chris Messina wrote:
So we're going to use SVN for managing our website and Drupal on our end, but for browser development, we're using something other than SVN.
okaaay.. so all those of us developing browsers should have a look at mercurial. i'm picking on you, but we're talking about a much larger development community than flock's (where it's mostly flock inc. + a few EFA's).
Things like good support on all platforms, and integrations in popular IDE's etc are pretty crucial to adoption.
I'm not particularly wedded to any SCM system... but right now, I think there are bigger things to worry about in the community than version control systems. I like SVN because it fixes some of CVS's braindeadedness without working too much differently.
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
James Walker wrote:
I'm not particularly wedded to any SCM system... but right now, I think there are bigger things to worry about in the community than version control systems. I like SVN because it fixes some of CVS's braindeadedness without working too much differently.
+1 Also, I'm not about to start wasting eyeball time reading a thread where everyone and his dog mentions his own mutually-incompatible alternative to cvs. And *nobody* (correct for rounding) is going to *touch* it if we're not using cvs or svn. Why on earth would I want to learn to use a different tool for each project I'm involved with? That's like using a different browser for each web site. Although I see we're also having _that_ discussion at the moment with respect to Mac users. [sigh]. jh
And *nobody* (correct for rounding) is going to *touch* it if we're not using cvs or svn. Why on earth would I want to learn to use a different tool for each project I'm involved with?
To quote James Blackwell from bzr: If that argument were true, everyone would be running windows xp, there would be no macs, and every webserver would be apache. :) and we'd all _still_ be running sendmail. =) CVS has been around for roughly forever, but it too displaced something else -- cssc and sccs. SVN has prided itself on retaining CVS's feel with the addition of a couple features. Which is fine, but would you really want to deal with something trying to be like CVS for the rest of your life?
On 11/16/05 3:24 AM, Karoly Negyesi wrote:
And *nobody* (correct for rounding) is going to *touch* it if we're not using cvs or svn. Why on earth would I want to learn to use a different tool for each project I'm involved with?
To quote James Blackwell from bzr:
If that argument were true, everyone would be running windows xp, there would be no macs, and every webserver would be apache. :) and we'd all _still_ be running sendmail. =) CVS has been around for roughly forever, but it too displaced something else -- cssc and sccs. SVN has prided itself on retaining CVS's feel with the addition of a couple features. Which is fine, but would you really want to deal with something trying to be like CVS for the rest of your life?
that's a pretty weak argument. first off, macs predate windows XP (and windows in general) - fraknly i've never run XP for anything... most webservers *are* apache... and as for sendmail... no we don't run sendmail we run things that are functionally equivalent to sendmail but much easier to setup & maintain and that have some added features. y'know ... kinda like svn vs. cvs. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 15 Nov 2005, at 11:24 PM, John Handelaar wrote:
That's like using a different browser for each web site. Although I see we're also having _that_ discussion at the moment with respect to Mac users. [sigh].
RIght! That's why I use Flock for every website :) Thanks for sharing the results of your review, Chris - I found it interesting and thought provoking. Any ideas why subversion is slow? DB implementation? Transactional model? Djun
Just for fun, how about gits... It works for the linux kernel :) On Wed, 2005-11-16 at 00:55 -0800, puregin wrote:
On 15 Nov 2005, at 11:24 PM, John Handelaar wrote:
That's like using a different browser for each web site. Although I see we're also having _that_ discussion at the moment with respect to Mac users. [sigh].
RIght! That's why I use Flock for every website :)
Thanks for sharing the results of your review, Chris - I found it interesting and thought provoking.
Any ideas why subversion is slow? DB implementation? Transactional model?
Djun
On Wed, 16 Nov 2005 22:35:15 +0100, Darrel O'Pry <dopry@thing.net> wrote:
Just for fun, how about gits... It works for the linux kernel :)
And nothing else. That's for Linux kernel and really nothing else. One workflow in mind, absolutely not a generic thing.
On Wed, 2005-11-16 at 22:41 +0100, Karoly Negyesi wrote:
On Wed, 16 Nov 2005 22:35:15 +0100, Darrel O'Pry <dopry@thing.net> wrote:
Just for fun, how about gits... It works for the linux kernel :)
And nothing else. That's for Linux kernel and really nothing else. One workflow in mind, absolutely not a generic thing.
Haven't even played with it, just stirring the water... I wouldn't mind seeing svn become the defacto... But I used both svn and cvs (excluding checkouts) for the first time in the last two weeks. They're alot easier to use than I expected.
2005/11/16, Darrel O'Pry <dopry@thing.net>:
Haven't even played with it, just stirring the water... I wouldn't mind seeing svn become the defacto... But I used both svn and cvs (excluding checkouts) for the first time in the last two weeks. They're alot easier to use than I expected.
http://wiki.gnuarch.org/SubVersionAndCvsComparison http://www.dwheeler.com/essays/scm.html http://better-scm.berlios.de/comparison/
SVN is still new but is already the winner: It will be the next defacto as it is an enhancement of CVS and keep the major compatibility with it (that's important for easy and safe migration...) That's exactly the way CVS overcome RCS :)
-- - when i come to cvs, what was great is i could migrate my rcs with ease - don't care, it will be easier to switch to svn
participants (12)
-
Adrian Rossouw -
Chris Messina -
Darrel O'Pry -
Gerhard Killesreiter -
Gildas COTOMALE -
James Walker -
John Handelaar -
Karoly Negyesi -
Kieran Lal -
Moshe Weitzman -
puregin -
Trae McCombs