RE: Subversion vs other source control systems
Santiago Gala wrote: Noel J. Bergman escribió: 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. You remember incorrectly. The mandate was to migrate from Infrastructure-managed CVS to Infrastructure-managed Subversion, not from CVS to the SCM of your choice. 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. There were a variety of reasons, including the above, but none of that addresses your apparent belief that the ASF should support ad hoc and arbitrary selections of critical infrastructure by individual projects. - 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 That is an extreme interpretation. I could as easily say that you are in favor of each project being able to maintain its own critical infrastructure on any servers anywhere with arbitrary security and community practices. I don't believe that is your actual view, but I could take your words to say so. - The infrastructure team is a Police body (to serve and protect) Saying that ensuring availability and safety (from loss and/or tampering) is one of the goals we have with respect to our data is hardly the same as your claim. Information can be copied and still stays the same, trying to restrict it to a server is really futile and wasting. I have no idea what you're talking about here. I don't think centralization has ever been part of the Apache way. But visibility of the content and process very much IS part of the Apache Way. Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes. We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete. We need to reeducate people who believe otherwise. That said, I am not saying that people can't use whatever SVN client(s) they want to use. I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Subversion vs other source control systems
Dirk-Willem van Gulik wrote: Ross Gardler wrote: 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. The issue isn't git as an SVN client. No one (as far as I know) cares what SVN client(s) you use, so long as they don't abuse our SVN server. 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; 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 most importantly, we want our development to be visible to the Community, not done in private and committed when finished. Developers can always make more or less transient branches to work on code, still in public view, and merge back to shared locations. The key point here that I believe you, I, William and others are all making isn't about technology, it is about practice. Now, if there is an SCM that substantially improves the ASF's ability to perform *our* practices, that is a separate discussion item. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Feb 17, 2008 7:51 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: But visibility of the content and process very much IS part of the Apache Way. Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes. We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete. We need to reeducate people who believe otherwise. That said, I am not saying that people can't use whatever SVN client(s) they want to use. I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF. +1. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote: Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. Let me fix that: Use case: work on apache project while on plane --- * export list of jiras of your favorite ASF project into spreadsheet * sync project repo to your laptop * get on a plane for 14 hours * slave away at the bug list, fixing a bunch * create one patch per bug, with a good commit message, referring to the bug report, and commit locally * get off the plane * get online * sync project repo to your laptop * resolve any conflicts * for each bug report * submit and commit the fix * close the bug report This is easy to do with git. It's a small nightmare with SVN, especially if your project is a million lines of code. (you could substitute while on plane with even if network craps out at hackathon or with at a customer site with big firewall) I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF. Exactly! cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xmlbeanscxx project revival
Hello, There is an ongoing development of xmlbeanscxx at TouK side, because of needs for this project. We are willing to provide our recently released version to Apache. We are also aiming at releasing version 1.0. There are 2 things left to implement to version 1.0: XPath evaluation and XmlCursor support. Those are partially implemented now. There is also a support for Microsoft Visual Studio compiler done using CMake build tool. Is it possible to revive this project at Apache Incubator? The latest version is currently released at sourceforge (http://sourceforge.net/project/showfiles.php?group_id=118556) due to closing down at Apache Incubator. Regards, -- Rafał Rusin www.mimuw.edu.pl/~rrusin
Re: Subversion vs other source control systems
El dom, 17-02-2008 a las 19:12 +0100, Leo Simons escribió: On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote: Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. Let me fix that: Use case: work on apache project while on plane --- * export list of jiras of your favorite ASF project into spreadsheet * sync project repo to your laptop * get on a plane for 14 hours * slave away at the bug list, fixing a bunch * create one patch per bug, with a good commit message, referring to the bug report, and commit locally * get off the plane * get online * sync project repo to your laptop * resolve any conflicts * for each bug report * submit and commit the fix * close the bug report This is easy to do with git. It's a small nightmare with SVN, especially if your project is a million lines of code. A big +1 on this use case. Have you tried this one? Also: you keep a long term branch for doing some refactoring, and you fix small bugs both in HEAD and in a release branch, merging and backporting/forwardporting as you go. Again, something like git makes the work simpler and keeps the disk requirements under control. (you could substitute while on plane with even if network craps out at hackathon or with at a customer site with big firewall) I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF. Exactly! Agreed too. cheers, - Leo - 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 dom, 17-02-2008 a las 10:58 -0500, Noel J. Bergman escribió: Dirk-Willem van Gulik wrote: Ross Gardler wrote: 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. The issue isn't git as an SVN client. No one (as far as I know) cares what SVN client(s) you use, so long as they don't abuse our SVN server. I think git-svn abuses the server a lot, as the subversion server is not designed for copying of the whole history. I agree that exporting svn to git/bazaar/mercurial, etc is a way forward, but it will cause strain to the svn server, for sure. As seen elsewhere, Jason took this path, and I'm actually using this technique in a number of places, both with git-svn and bzr-svn. I will keep reporting. I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? I already answered to this one in the thread. - faster commits, branch switching, pulls and pushs - merges, good and persistent merges - offline work, offline history diffs - rebasing is not such a feature, but it can be useful sometimes - publishing lots of repositories helps surfacing patches that are currently hidden until ready for sending/committing I hope helping each and every developer/contributor counts as helping 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; 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. huh? every vendor keeping patches against apache repositories is merging often. I don't follow your reasoning, anybody keeping patches is merging repeatedly against a moving HEAD (for active projects). In my view, every developer that maintains patches is in effect having a *private, unpublished* branch. With git and a setup like the one in kernel.org, all those patches are suddenly public, visible. Think about it. And most importantly, we want our development to be visible to the Community, not done in private and committed when finished. Developers can always make more or less transient branches to work on code, still in public view, and merge back to shared locations. The key point here that I believe you, I, William and others are all making isn't about technology, it is about practice. The inability of subversion to remember merged results makes working in a branch unpractical. Been there, done that, very tricky. Personal repositories can be kept in public, you just can look into the different branches in http://git.kernel.org/?p=linux/kernel to see how a number of those are updated a lot. Turning your key poing upside down: We should not try to impose our practices using a technological tool, specially when doing so impairs development. Now, if there is an SCM that substantially improves the ASF's ability to perform *our* practices, that is a separate discussion item. I'm quite sure currently any one of git, bazaar, mercurial or even darcs would improve our practices. Just to make sure, my view of the discussion: people *against* changes in SCM is blaming a hypothetical introduction of git of breaking the ASF practices I don't think the discussion is, and never was presented as: evil revolutionaries wanting to break the practices by introduction of sneaky solipsistic tools. I don't think git will break ASF practices more than keeping quilt patches, or several repositories, to survive svn up without nasty conflicts. 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
On Feb 17, 2008 3:34 PM, Santiago Gala [EMAIL PROTECTED] wrote: Also: you keep a long term branch for doing some refactoring, and you fix small bugs both in HEAD and in a release branch, merging and backporting/forwardporting as you go. Again, something like git makes the work simpler and keeps the disk requirements under control. In an attempt to stop some of the outright FUD in this thread before it goes on to yet another mailing list... I've found that svnmerge.py (distributed with SVN) handles pretty much all of the branch/merge tracking capabilities that I personally care about. (The drawback is that it isn't as efficient as we'd like, but it's good enough. The 1.5 stuff is *way* faster.) From your statements, you probably haven't bothered to try svnmerge.py (usable with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It makes it pretty brain-dead simple to handle most branch-oriented merging cases. There are a few pathological cases that don't work well, but that's 'reflective' merging which isn't the 95% use case - so it got punted to post-1.5. (svnmerge.py is probably the 80% use case, with 1.5 merge tracking being 90%, and reflective merging being that last gap...) FWIW, for svn.apache.org, I have a feeling we'll probably be a tad aggressive on rolling out 1.5. (Besides merge tracking, there are a number of excellent features in 1.5: changelist support, interactive conflict resolution, read/write transparent proxies, integrated 'diff -x -p' support, substantial svnsync speed improvements, partial svnsync ability, etc.) Note that nothing is stopping you from using svnmerge.py today. If folks are going to complain about switching to another SCM because of a lack of decent merging, then they owe it to themselves to check out what Subversion can actually do rather than what they think it can do... -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On 2/17/08, Noel J. Bergman [EMAIL PROTECTED] wrote: But visibility of the content and process very much IS part of the Apache Way. Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes. We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete. We need to reeducate people who believe otherwise. That said, I am not saying that people can't use whatever SVN client(s) they want to use. I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF. With all the recent interest in distributed version control, I decided to do some research. I looked at git, hg and bzr and nothing that I read out there convinced me that any of them offers a significant advantage over SVN. So I decided to try one. The productivity gain was enough to win me over. My experience is that it works much better especially for projects that involve a distributed community of developers. DVC do not use the same terminology as SVN. With SVN you check out code into your local working copy, with DVC the working copy is a repository, so checking out is effectively creating a branch. Likewise, you do not commit from working copy to central repository, but merge from your local repository to a more authoritive one. So I can see how it sounds like developers on DVC are working in the dark on big changes outside of community visibility, but only because with SVN branches tend to encapsulate large changes. In DVC branching and merging are done instead of checkout and commit, there's nothing anti-social about this practice. It's also only when you consider that every svn update and svn commit is essentially a merge (in DVC terminology) that you realize how frequent merges are, any why any small improvment on merge is a significant benefit. My experience is mostly with small projects, and it does make a difference even when working in small teams, so definitely something we should consider for incubation projects. In fact, I think it will be easier and lower risk to start the journey to DVC there. Assaf
