Re: Subversion vs other source control systems
Paul Querna wrote: Santiago Gala wrote: El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió: No. 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. Making requests to a closed team Infrastructure isn't a closed team by any means, and I am tired of people propagating that bullshit. Come help, and karma comes. in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. infrastructure is open to all committers. infrastructure-dev is open to all committers. infrastructure-private is open to all members. Why should this discussion be moved into a Apache-private realm, and not just stay fully public, so that I can watch the proceedings? This is an interesting discussion. So far, Santiago has some pretty neat arguments going! :-) Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Endre Stølsvik wrote: Why should this discussion be moved into a Apache-private realm, and not just stay fully public, so that I can watch the proceedings? This is an interesting discussion. Can we please keep the Incubator ML focused ??? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Justin Erenkrantz wrote: On Feb 18, 2008 10:48 AM, Santiago Gala [EMAIL PROTECTED] wrote: outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences I feel there has been lots of FUD and if you don't realize that, then I recommend taking a step back. Please define FUD for us, will you? Because I haven't seen one single iota of FUD on this thread - it has stayed strangely on topic, with good arguments from both sides, and not once has the discussion gone into SCM XYZ often ruins the code base by introducing strange bit errors-style half-lies which is what I associate with FUD. A/k/a The Microsoft Tactics in regards to Linux. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
On 19/02/2008, Simon Nash [EMAIL PROTECTED] wrote: snip/ One topic from the tuscany-user discussion that's worth exposing here is whether the NNY project would be a pure RI with no extensions beyond the spec, or a vehicle for innovation to extend the specs, as both Tuscany SCA and SDO have been. My view is that it will need to be at least some of the latter in order to build a sustainable community of developers and users. +1 This will create some challenges given that one of the goals of the NNY project is to deliver the official JCP RI. Simon snip/ I just asked a question on the jcp-open mailing list to find out how other projects that do RIs in Apache handle the apparent contention. It should appear under a February 2008 heading in the mailing list archive at [1] shortly. Kelvin. [1] http://mail-archives.apache.org/mod_mbox/www-jcp-open/
Re: FWD: [VOTE] Bharath Ganesh for CXF committer....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 from me. - -- dims 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! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFHuyj6gNg6eWEDv1kRAhMPAJ4qmj11TlBWd0b8IYrAelwlDivVkwCgr2dL q/Zr11Jm4ze5Rh188XJLwSA= =pxLr -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Tue, 2008-02-19 at 11:51 +0100, Endre Stølsvik wrote: Justin Erenkrantz wrote: On Feb 18, 2008 10:48 AM, Santiago Gala [EMAIL PROTECTED] wrote: outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences I feel there has been lots of FUD and if you don't realize that, then I recommend taking a step back. Please define FUD for us, will you? Because I haven't seen one single iota of FUD on this thread - it has stayed strangely on topic, with good arguments from both sides, and not once has the discussion gone into SCM XYZ often ruins the code base by introducing strange bit errors-style half-lies which is what I associate with FUD. A/k/a The Microsoft Tactics in regards to Linux. I'm not going to argue whether there specifically is FUD, but there is _serious_ underestimation of what it takes to roll out something as crucial as source control within an organisation the size of Apache, and with a repository the size of Apache. Justin put it very well in a related thread elsewhere (permission sought): - o - The JAMES PMC knows that if they want to run on apache.org, they have to handle *all* of the list traffic - not just their list. So far, they've not made a request to do so. In some cases, it doesn't have to be total conversion - for example, in infra, we're very hopeful that we can run Harmony in some cases where we run Java - but Harmony is not yet capable of running Confluence, so we can't switch over. But, for a SCM, it *must* be on a path towards total conversion - nothing less is acceptable, IMO. We will *not* have a fractured repository system like FreeBSD or Perl. If a PMC asked to run their own individual SCMs, they'd simply be turned down. If we switch our SCM to anything else, *everything* must switch over. IMO, at this point, we simply do not have anything other than a few people who may have used git a few times - but we certainly don't have any folks who appear willing to step up and realistically and soberly consider what it means to change *everything* over. Compare and contrast our experience with Subversion and let that *truly* sink in if you're even a bit flippant about what it means to switch. Converting from CVS to Subversion took *years* to accomplish and it took a *lot* of us getting deep inside the SVN community and codebase to make sure it'd work for us. Converting to something else would take a realistically long time as well with a concomitant set of expectations that folks will actively improve the tool to meet our requirements. So far, all I'm seeing is a few people saying, It'd be nice if someone else converts the ASF to git. Those comments are completely irrational and misguided as to how we work. If you're so bent on getting us on another SCM, then join the infrastructure list and start proving that it's better than SVN. FWIW, git and mercurial (mercurial is *far* better than git in my experience; it's not even close, to be honest) do not scale well to *really* *really* large repositories. If you look at KDE's trial migration to git (which Joe and myself and others are watching closely), they are separating every KDE deliverable into a separate git repository. (That is, every KDE library gets its own git repository - so kdelibs and kdedesktop are treated separately.) KDE is explicitly willing to lose history when they move things between repositories. I'm frankly not sure that we'd find that acceptable. Mercurial has sketched out a concept of 'forests' (of related repositories), but again they're not thinking in terms of anything other than an individual codebase - certainly not 25GB+ and across 60+ TLPs. And, AFAICT, the concept of 'forests' is sketchy and not a part of the core Mercurial codebase (think svn:externals and you've got an idea how they implemented 'forests'). Again, with those SCMs, they're perfectly willing to sacrifice history as it moves across those small repositories as cross-project history is not something they care to support. - o - Now, that, in my impression, puts the situation very well. If we were to switch to git, or anything else, there would be huge issues involved, and would be probably years of work to manage the transition. If that is what is generally wanted, then we need volunteers who will put themselves behind the task. No small feat. I have seen such changes happen at Apache - they can, but the issues involved from an infrastructure point of view are invariably an order of magnitude (if not two orders) harder than those you see on one's own, typically smaller, installations. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bharath Ganesh for CXF committer....
+1 On 2/19/08, Daniel Kulp [EMAIL PROTECTED] 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Upayavira wrote: Justin put it very well in a related thread elsewhere (permission sought): [ CHOP interesting adamant view from Justin ] (Where is elsewhere, btw?) What I find strange in all this is the view that ALL projects at Apache would have to change to OtherSCM if one project would want that.. Indeed, 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, for example, would be great (AFAIK, TLP-promotion can be handled too with history preserved). This would help in every single aspect in regard to the volume of source and activity, could use multiple servers etc - and incidentally using another SCM for a particular project wouldn't be that big a deal anymore. The only downside I see is a slight bit more configuration management, and that copying/moving a file from one repo to another would not keep history that well. How often does this happen, though? However, I'm no SVN expert, so I can easily have misunderstood everything. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Tue, 2008-02-19 at 22:29 +0100, Endre Stølsvik wrote: Upayavira wrote: Justin put it very well in a related thread elsewhere (permission sought): [ CHOP interesting adamant view from Justin ] (Where is elsewhere, btw?) Apache has a number of internal lists on which members communicate amongst themselves regarding the organisation and operation of the Foundation. What I find strange in all this is the view that ALL projects at Apache would have to change to OtherSCM if one project would want that.. (a) we couldn't manage it otherwise, purely in terms of volunteer time (b) we would have a disjoint set of the Foundation's core asset, which might be acceptable temporarily, but would not as an ongoing situation. Indeed, 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, for example, would be great (AFAIK, TLP-promotion can be handled too with history preserved). This would help in every single aspect in regard to the volume of source and activity, could use multiple servers etc - and incidentally using another SCM for a particular project wouldn't be that big a deal anymore. The only downside I see is a slight bit more configuration management, and that copying/moving a file from one repo to another would not keep history that well. How often does this happen, though? However, I'm no SVN expert, so I can easily have misunderstood everything. The thing is, that we're working with an order of magnitude more complexity here. Setting up a wiki, you'd think that was relatively simple task. However, once we'd set up MoinMoin wiki, we found it couldn't handle the traffic, and entered upon a 2 month hacking bonanza to get some kind of caching in front of it so that it would actually stay up and respond in reasonable time. And that was only one of the issues. We had similar issues in the early days of SVN, and we would hve similar issues in the early days of _any_ new piece of technology that is introduced here. That is why infra folks are resistant - they have, by direct experience, knowledge of what it is like to change this kind of stuff. HTH. Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] (2) Release NMaven 0.15-incubating
We have a new vote going on to release NMaven 0.15-incubating. I've addressed most of the issues raised in the last vote on [EMAIL PROTECTED] Rather than serializing the votes across the PPMC and the IPMC again, I'd like to just have one vote. You can find the ongoing vote here: http://www.nabble.com/-VOTE--%282%29-Release-NMaven-0.15-incubating-td15575008.html Thanks, Shane
Re: Subversion vs other source control systems
El mar, 19-02-2008 a las 22:29 +0100, Endre Stølsvik escribió: Upayavira wrote: Justin put it very well in a related thread elsewhere (permission sought): [ CHOP interesting adamant view from Justin ] (Where is elsewhere, btw?) the discussion spread to a private list outside here. We should move this kind of discussion to a different public list, I guess it is mostly out of scope in [EMAIL PROTECTED] (except in the what is the apache way, probably) I will try to post a followup in community, again. What I find strange in all this is the view that ALL projects at Apache would have to change to OtherSCM if one project would want that.. I also find it strange. I guess it spreads from the fact that subversion (or old cvs) can only preserve history easily when moving inside the same repository. I made an experiment, which I will publish in a blog entry, where I pulled from repo2 into repo1 for two git repos. This is easy and works, provided that there are no name collisions that are not supposed to be merged together. If I have a hypothetical podling1 repo and another hypothetical targetTLP1 repo, I could (say on graduation) do: cd podling1 git-branch to_target1 git-checkout to_target1 mkdir target-tree git mv * target-tree #* does not work but you get the idea... git-commit -a -m this is for targetTLP after graduation cd ../targetTLP1 git-branch merge_podling1 git-checkout merge_podling1 git-pull ../podling1 #it could be a remote repo too ... git commit -a -m merged podling1 in targettree gitk --all #to view the merged repos, it has a new tree in target-tree And proceed moving code around or merging as appropriate. (Not sure how would hg or bzr handle this use case). I don't know how this would work in practice, there is a need to experiment this kind of things to find corner cases and problems. But I think, as you comment in the following paragraph, that it buys us lots of extra flexibility and scalability. Indeed, 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, for example, would be great (AFAIK, TLP-promotion can be handled too with history preserved). This would help in every single aspect in regard to the volume of source and activity, could use multiple servers etc - and incidentally using another SCM for a particular project wouldn't be that big a deal anymore. The only downside I see is a slight bit more configuration management, and that copying/moving a file from one repo to another would not keep history that well. How often does this happen, though? Actually, if you try the above as I have done with a couple of small repos, it keeps the whole history, including moves, committer info, etc. Typically modern SCM (this includes subversion FWIK) don't version files, but rather store graphs of commits/changesets. This means that pulling a commit from a different repository will go pulling parent commits up to the first common commit or, lacking it, to the root of the history. Regards Santiago However, I'm no SVN expert, so I can easily have misunderstood everything. Endre. - 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
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. The only downside I see is a slight bit more configuration management Don't be so blithe about that. and that copying/moving a file from one repo to another would not keep history Unacceptable to lose it, IMO. And you'd be surprised how often things move around. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Subversion vs other source control systems
Santiago Gala wrote: - publishing lots of repositories helps surfacing patches that are currently hidden until ready for sending/committing The last one is almost antithetical to how we want people to work. Can you elaborate on how is publishing what currently is hidden antithetical to how we want people to work? I think that getting a clear idea on this is important, as I always thought the ASF was about transparency and not keeping information hidden. Let us clarify, then. I am saying that developers doing extensive work in their own repositories, and periodically merging bulk changes to the communal repository is antithetical to how we want people to work, which is to be working in the shared repository, on a frequent and fine-grained manner, even if in different branches. The inability of subversion to remember merged results makes working in a branch unpractical. Been there, done that, very tricky. Raise any technical issues with the Subversion folks. huh? why? Because you are attempting to raise a technical issue regarding our source control system, and they are the ones who would best respond to it. 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. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
