RE: Subversion vs other source control systems
El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió: Endre Stølsvik wrote: I find the decision to use one single SVN repo for the entire organization's source pretty strange. I'd believe that one repo for every TLP Been there, done that, have the scars. Possibly using several *centralized* repositories that can't merge. May we know more? If not, I call FUD ask the jury to ignore the statement. :) The only downside I see is a slight bit more configuration management Don't be so blithe about that. I actually think management would be way smaller. And, what is more important, distributable per repository. and that copying/moving a file from one repo to another would not keep history Unacceptable to lose it, IMO. Can be done without losing history. See separate email. And I have done the same test with hg (basically the same) and bazaar (which required some command line tweaking, but doable). And you'd be surprised how often things move around. If you take a look into the basic development model in the linux kernel, it means moving history between repositories continuously (say from am to net to linus,...) Every line of code is tracked while it moves, in fact when Linus merges from, say, the acpi tree, the commits remain identical. Regards Santiago (I add cc: and reply-to: community) --- 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
Hi, On 2/20/08, Noel J. Bergman [EMAIL PROTECTED] wrote: This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator. I already tried to move the discussion to [EMAIL PROTECTED], where I think it belongs, but people insists on answering here. I understand, but that still doesn't make it an issue for the Incubator. Actually, I'd expect the incubator to be exactly where such discussions would crop up, as the new blood challenge the status quo and seek to make sense of how things are done here. And, indeed, this should be extremely valuable for the community as a whole, as it's a chance to document our rationales, or to re-evaluate methodologies that are rendered obsolete by newer technologies. (Not that I think SVN is obsolete, but I do see some serious value in reappraising the centralised vs. distributed model of development to see what is possible within the Apache Way, or even if the Apache Way should be updated.) Andrew. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept CouchDB for incubation - PASSED!
Hey, On Sun, Feb 17, 2008 at 10:16:27PM -0800, Ted Leung wrote: I've just submitted a request for the appropriate mailing lists. You can track via: https://issues.apache.org/jira/browse/INFRA-1526 I just realised that the original proposal makes no mention of a wiki. We're currently using http://www.couchdbwiki.com/ but I am guessing it would be nice to move this over to Apache's infrastructure. Thanks, -- Noah Slater http://bytesexual.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
[Apologies to incubator readers if you get this twice] On 20/02/2008, Santiago Gala [EMAIL PROTECTED] wrote: El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió: Endre Stølsvik wrote: I find the decision to use one single SVN repo for the entire organization's source pretty strange. I'd believe that one repo for every TLP Been there, done that, have the scars. Possibly using several *centralized* repositories that can't merge. May we know more? If not, I call FUD ask the jury to ignore the statement. :) The only downside I see is a slight bit more configuration management Don't be so blithe about that. I actually think management would be way smaller. And, what is more important, distributable per repository. Even if a smaller repository causes less work, there will necessarily be some overhead per different repository - e.g. upgrades. Switching between different repositories to work on them will generate some overhead (if only having to think about it). Which is easier to manage: 30 accounts with various different banks, or one bank account with 30 times the transactions? The work is only distributable to the extent that there are multiple people to whom to distribute it; and certain actions would likely still need to be co-ordinated between them. and that copying/moving a file from one repo to another would not keep history Unacceptable to lose it, IMO. Can be done without losing history. See separate email. And I have done the same test with hg (basically the same) and bazaar (which required some command line tweaking, but doable). And you'd be surprised how often things move around. If you take a look into the basic development model in the linux kernel, it means moving history between repositories continuously (say from am to net to linus,...) Every line of code is tracked while it moves, in fact when Linus merges from, say, the acpi tree, the commits remain identical. Regards Santiago (I add cc: and reply-to: community) Thanks. --- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On 20/02/2008, Santiago Gala [EMAIL PROTECTED] wrote: El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió: Endre Stølsvik wrote: I find the decision to use one single SVN repo for the entire organization's source pretty strange. I'd believe that one repo for every TLP Been there, done that, have the scars. Possibly using several *centralized* repositories that can't merge. May we know more? If not, I call FUD ask the jury to ignore the statement. :) The only downside I see is a slight bit more configuration management Don't be so blithe about that. I actually think management would be way smaller. And, what is more important, distributable per repository. Even if a smaller repository causes less work, there will necessarily be some overhead per different repository - e.g. upgrades. Switching between different repositories to work on them will generate some overhead (if only having to think about it). Which is easier to manage: 30 accounts with various different banks, or one bank account with 30 times the transactions? The work is only distributable to the extent that there are multiple people to whom to distribute it; and certain actions would likely still need to be co-ordinated between them. and that copying/moving a file from one repo to another would not keep history Unacceptable to lose it, IMO. Can be done without losing history. See separate email. And I have done the same test with hg (basically the same) and bazaar (which required some command line tweaking, but doable). And you'd be surprised how often things move around. If you take a look into the basic development model in the linux kernel, it means moving history between repositories continuously (say from am to net to linus,...) Every line of code is tracked while it moves, in fact when Linus merges from, say, the acpi tree, the commits remain identical. Regards Santiago (I add cc: and reply-to: community) Thanks. --- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bharath Ganesh for CXF committer....
+1 --kevan On Feb 19, 2008, at 2:05 PM, Daniel Kulp wrote: We held a vote on cxf-dev to grant commit karma to Bharath Ganesh in recognition of his many valuable contributions: Thread: http://www.nabble.com/-VOTE--Bharath-Ganesh-for-committer-to15511330.html We ended up with 13 +1 votes, but only 2 (right now, gnodet and bsnyder) are IPMC binding. We would greatly appreciate it if others could take a look and vote. Thanks! -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
