Re: Subversion vs other source control systems
Noel J. Bergman wrote: J Aaron Farr wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Leo already gave a decent explanation. Basically, it comes down to two aspects: 1) infrastructure support 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: 1. You have to use subversion. Sorry, I've missed the thread that led to this, so sorry if I'm repeating others. I understand that GiT can be used locally as a layer on top of SVN. I believe this gives you most of the perceived benefits of GiT locally without the need for a project itself to switch to GiT. Now, I've never tried this and don't know anyone who has, but thought I'd flag it in case it is relevant. Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote: Noel J. Bergman wrote: J Aaron Farr wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Leo already gave a decent explanation. Basically, it comes down to two aspects: 1) infrastructure support 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: 1. You have to use subversion. Sorry, I've missed the thread that led to this, so sorry if I'm repeating others. I understand that GiT can be used locally as a layer on top of SVN. I believe this gives you most of the perceived benefits of GiT locally without the need for a project itself to switch to GiT. I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? One of the great things about GiT is that you can can have lots of parallel and non-linear merges (every developer their own branch; lots of people merging the same patch into different sequences) -- and as such I can see it being perfectly tuned for, say, Linux. However in the ASF most groups work roughly along fairly linear lines; with 'one' or just a 'few' points at which a patch is accepted - and essentially few, or just one, merge point (or a single line of merge points when backported). Rarely do we merge multiple 'HEAD's. And I'd almost argue that SVN is a useful framework which helps us stay on the paved roads - where a single head progresses with group consensus and generally agreed merit. Thanks, Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
El mié, 13-02-2008 a las 18:28 -0500, Noel J. Bergman escribió: J Aaron Farr wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Leo already gave a decent explanation. Basically, it comes down to two aspects: 1) infrastructure support 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: 1. You have to use subversion. Why? Has been a vote done? where? I vote +1 for git if a vote is still open. No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. No project was allowed to stay with CVS. No project will be allowed to use another source control system unless it is adopted at the ASF level. Source code is a critical, shared, public resource maintained by the Foundation, not something whose storage is managed on a project by project basis. The Infrastructure Team maintains and protects that shared resource on behalf of the Foundation. If I remember correctly, the policy was not to impose subversion, but to mandate end of life for CVS. If I remember correctly, this was due to security concerns, CVS requiring user accounts in the machine where the repository is stored while subversion does not. Also functionality. Also that having a lengthy transition was stressing infrastructure. I have been looking into mail archives but have not found a pointer yet. Funny enough, all people using distributed SCM quoted ease and simplification of administration as one of the core advantages, be it git, bazaar, mercurial or darcs. If I read correctly your last two sentences, I see that - you are no longer considering the Foundation as an umbrella for the projects, but as an entity with a life that, I see from your reaction, needs to protect itself from the (some?) projects - The infrastructure team is a Police body (to serve and protect) Information can be copied and still stays the same, trying to restrict it to a server is really futile and wasting. The only thing that actually would need a custody would be a PGP-signed text document with SHA1 of the release source and date. And I don't think it would be signed by the infrastructure team, but by the three +1 voters of the release in the PMC. And this custody can easily be achieved by publishing in a multiply archived email list. I don't think centralization has ever been part of the Apache way. Regards Santiago --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Janne Jalkanen wrote: No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. I would assume though that if there is enough interest among the community, the subject of supporting something like Git could be opened up with the Board, yes? It's up to the infrastructure team to decide, the board is generally hands-off when it comes to their decisions for the foundation. So it needs to be brought up to them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió: On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote: Noel J. Bergman wrote: J Aaron Farr wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Leo already gave a decent explanation. Basically, it comes down to two aspects: 1) infrastructure support 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: 1. You have to use subversion. Sorry, I've missed the thread that led to this, so sorry if I'm repeating others. I understand that GiT can be used locally as a layer on top of SVN. I believe this gives you most of the perceived benefits of GiT locally without the need for a project itself to switch to GiT. I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? It adds: - ability to have offline commits - much faster repository diff, status, etc. that works offline - (git-specific) ability to reorder and aggregate several private commits to deliver a consistent patch. This can only be simulated with other tools - ability to publish (push/pull) branches easily for tests without compromising the main line. Subversion branches, while easy to create, are awful to maintain and rarely used. - clean and remembered merges: patches with clear attribution that can be merged multiple times which, again, makes easy maintenance of several branches running in parallel.Backports, etc. One of the great things about GiT is that you can can have lots of parallel and non-linear merges (every developer their own branch; lots of people merging the same patch into different sequences) -- and as such I can see it being perfectly tuned for, say, Linux. Precisely the fact that patches are accepted in just 'one' or 'a few' points make invaluable having good maintenance of in-progress work. However in the ASF most groups work roughly along fairly linear lines; with 'one' or just a 'few' points at which a patch is accepted - and essentially few, or just one, merge point (or a single line of merge points when backported). Rarely do we merge multiple 'HEAD's. Not in my experience, it is common to have in-progress work in parallel with bugfixes, etc. subversion is awful for tracking multiple branches in parallel, to the point that I have been using quilt for patch management of top of subversion. This is clearly a kludge that reveals the deficiencies of the workflow. You see? rarely do we merge multiple HEADs is seen from the point of view of the repository. If you have 10 developers working on patches, you have 10 people merging continuously their branch with the official one. Rarely applies only to the subversion repo. And I'd almost argue that SVN is a useful framework which helps us stay on the paved roads - where a single head progresses with group consensus and generally agreed merit. I've seen plenty of times where having in-progress patches were consistently conflicted by commits, which multiplied the work implied in keeping them to the point of dropping them (personal). This is trivially easy to do with bazaar or git, and I'm quite sure that darcs or mercurial will offer the same comfort level. At least for my development style, distributed SCM offers one order of magnitude more comfortable environment than centralized SCM. As for your concrete sentence, I'd say that if you need a technical tool as a framework to impose a work flow, then the work flow is possibly broken. If the work flow is sound, having a tool that eases the work won't break it. Regards Santiago (who was working to deliver this and more info on technical merits in the [EMAIL PROTECTED] thread) Thanks, Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
El jue, 14-02-2008 a las 10:52 +, William A. Rowe, Jr. escribió: Janne Jalkanen wrote: No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. I would assume though that if there is enough interest among the community, the subject of supporting something like Git could be opened up with the Board, yes? It's up to the infrastructure team to decide, the board is generally hands-off when it comes to their decisions for the foundation. So it needs to be brought up to them. I'd say that if a project wants to have a distributed scm and makes a reasonable case of the reasons, they would ask for it to infrastructure. If infrastructure denies it and the project does not accept the reasoning or how it is exposed, we have a conflict. If there is a conflict the Board *has* to consider the issue. I'm not sure on how it is worded in the bylines. While we typically value consensus a lot, we typically don't take bureaucratic answers as absolutes. Or at least that is how I remember the ASF used to be. :P Also, while all users have http://people.apache.org/~userid/ , a git/bazaar/mercurial/darcs repo is only one scp away. I have set up cvs, subversion, git and bazaar, and the last two were vastly easier to set up and maintain. As I said, specially if ssh/sftp is there. The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community. Regards Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On 14.02.2008, at 14:14, Santiago Gala wrote: ... The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community. Aye, and this is also the reason why it potentially conflicts with the meritocratic model of the ASF; furthermore there are also legal hurdles to cross etc. In the end I think it's simply too early to discuss all this - let's wait until some project comes up with a well-prepared and clearly defined proposal to change their SCM. IMHO this is certainly not a task for the Incubator or a podling... Cheers, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele [EMAIL PROTECTED] wrote: Aye, and this is also the reason why it potentially conflicts with the meritocratic model of the ASF; furthermore there are also legal hurdles to cross etc. In the end I think it's simply too early to discuss all this - let's wait until some project comes up with a well-prepared and clearly defined proposal to change their SCM. IMHO this is certainly not a task for the Incubator or a podling... Agreed. It's better to wait. Also note, that: - For obvious reasons, git and other distributed VC systems are more suited for larger projects with a real lot of contributors. Even in the case of the top level projects, there aren't too many that qualify for that. - Even now, it is possible to work with git, if you want to: See http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/[EMAIL PROTECTED] I do not know how far Jason van Zyl's attempts have grown or not, but the point is that his intentions have been to gather experience. Anyone else is free to do the same. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Santiago Gala wrote: I'd say that if a project wants to have a distributed scm and makes a reasonable case of the reasons, they would ask for it to infrastructure. If infrastructure denies it and the project does not accept the reasoning or how it is exposed, we have a conflict. If there is a conflict the Board *has* to consider the issue. I'm not sure on how it is worded in the bylines. Well, yes, board is the appeal of last resort. But just like the board rarely touches the third rail of making development decisions for a project, they rarely make architectural decisions overriding infrastructure. The right way is for infra to determine they won't do it unless ___ happens, and appeal to the board to make ___ happen on behalf of the requester. While we typically value consensus a lot, we typically don't take bureaucratic answers as absolutes. Or at least that is how I remember the ASF used to be. :P You can't have a less absolute bureaucratic result than bringing an issue to the board ;-) The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community. But there's a deep question of if this goes against the principals of the meritocracy of peers that has worked so well for the ASF. We don't and wouldn't entertain such roles as code wrangler, project lead, etc. It's just not our ethos/social schema. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
El jue, 14-02-2008 a las 14:32 +0100, Erik Abele escribió: On 14.02.2008, at 14:14, Santiago Gala wrote: ... The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community. Aye, and this is also the reason why it potentially conflicts with the meritocratic model of the ASF; furthermore there are also legal hurdles to cross etc. I can't see where are the legal or meritocratic problems, really. Specially the legal ones. A changeset is a changeset, whereas it is stored in subversion, several git repos or a patch in jira. I can agree that some experimentation is needed to refine the work flows and see how it works with our models, but denial will not help getting work done in this area. In the end I think it's simply too early to discuss all this - let's wait until some project comes up with a well-prepared and clearly defined proposal to change their SCM. IMHO this is certainly not a task for the Incubator or a podling... Neither is a task for the incubator PMC to freeze the new teams, and cut off the fresh air from the ASF. Raising an expectation that you *can* defy the powers-that-be here was my main aim in this whole thread. :) Cheers, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
El jue, 14-02-2008 a las 14:45 +0100, Jochen Wiedmann escribió: On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele [EMAIL PROTECTED] wrote: Aye, and this is also the reason why it potentially conflicts with the meritocratic model of the ASF; furthermore there are also legal hurdles to cross etc. In the end I think it's simply too early to discuss all this - let's wait until some project comes up with a well-prepared and clearly defined proposal to change their SCM. IMHO this is certainly not a task for the Incubator or a podling... Agreed. It's better to wait. Also note, that: - For obvious reasons, git and other distributed VC systems are more suited for larger projects with a real lot of contributors. Even in the case of the top level projects, there aren't too many that qualify for that. I don't see the obvious reasons, of course excepting much better performance of git. I mostly use bazaar for small projects, for instance put /etc of a group of servers under version control, and have the ability to commit remote configuration changes and then push to/pull from the remote server. I think the smaller management overhead of bazaar or git makes it easier than having to set up and protect svn server and repositories. - Even now, it is possible to work with git, if you want to: See http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/[EMAIL PROTECTED] I do not know how far Jason van Zyl's attempts have grown or not, He is making basically the same points I tried to make, and with a lot of enthusiasm too... I hope this will help convincing people to try any of the tools. but the point is that his intentions have been to gather experience. Anyone else is free to do the same. Well, I answered to Noel's: No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. because he was clearly implying that no, nobody is free to do the same. Now at least I see that I'm not alone here. And hopefully people in podlings will see that we are a bit less uniform and bureaucratic than they were fearing. :) Regards Santiago Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Proposal] NoNameYet : Link Error - please use this link
In my opinion SCA and SDO are two completely different technologies, even if they can be used together, they address different problems and as specifications they are developed separately. I think there are a lot of people looking only at SDO for their projects, and I'm sure there are others looking at SCA without SDO. I think having each community focus on their goals would help getting better organized, develop and independently graduate. Other than the technology/community point of view, the SDO code is not dependent on SCA code and as Ant Elder pointed out on Tuscany-user list (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02505.html ) the new infrastructure would seem a better fit. Cezar -Original Message- From: Paul Fremantle [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:50 AM To: general@incubator.apache.org Subject: Re: [Proposal] NoNameYet : Link Error - please use this link Cezar I don't think anyone has suggested this code is a fork from Tuscany, but thank you for making this completely clear. Is there any reason you aren't willing to do this work under the existing scope of the Tuscany Incubator project? Paul Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
Cesar The Tuscany project is aiming to have the following charter: charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. Are you saying that SDO falls out of that scope? Paul On Thu, Feb 14, 2008 at 8:31 PM, Cezar Andrei [EMAIL PROTECTED] wrote: In my opinion SCA and SDO are two completely different technologies, even if they can be used together, they address different problems and as specifications they are developed separately. I think there are a lot of people looking only at SDO for their projects, and I'm sure there are others looking at SCA without SDO. I think having each community focus on their goals would help getting better organized, develop and independently graduate. Other than the technology/community point of view, the SDO code is not dependent on SCA code and as Ant Elder pointed out on Tuscany-user list (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02505.html ) the new infrastructure would seem a better fit. Cezar -Original Message- From: Paul Fremantle [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:50 AM To: general@incubator.apache.org Subject: Re: [Proposal] NoNameYet : Link Error - please use this link Cezar I don't think anyone has suggested this code is a fork from Tuscany, but thank you for making this completely clear. Is there any reason you aren't willing to do this work under the existing scope of the Tuscany Incubator project? Paul Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
Actually I'm wrong The correct wording (I think) is: ..establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the SCA and SDO standards defined by the OASIS OpenCSA member section. Same question applies. Paul On Thu, Feb 14, 2008 at 9:24 PM, Paul Fremantle [EMAIL PROTECTED] wrote: Cesar The Tuscany project is aiming to have the following charter: charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. Are you saying that SDO falls out of that scope? Paul On Thu, Feb 14, 2008 at 8:31 PM, Cezar Andrei [EMAIL PROTECTED] wrote: In my opinion SCA and SDO are two completely different technologies, even if they can be used together, they address different problems and as specifications they are developed separately. I think there are a lot of people looking only at SDO for their projects, and I'm sure there are others looking at SCA without SDO. I think having each community focus on their goals would help getting better organized, develop and independently graduate. Other than the technology/community point of view, the SDO code is not dependent on SCA code and as Ant Elder pointed out on Tuscany-user list (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02505.html ) the new infrastructure would seem a better fit. Cezar -Original Message- From: Paul Fremantle [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:50 AM To: general@incubator.apache.org Subject: Re: [Proposal] NoNameYet : Link Error - please use this link Cezar I don't think anyone has suggested this code is a fork from Tuscany, but thank you for making this completely clear. Is there any reason you aren't willing to do this work under the existing scope of the Tuscany Incubator project? Paul Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
