Re: Subversion vs other source control systems
There is now a list to discuss this kind of things, infra-dev. I CC: it. Please drop the email to [EMAIL PROTECTED] if you answer. El mar, 08-04-2008 a las 08:17 +0100, Danny Angus escribió: On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala [EMAIL PROTECTED] wrote: 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. That's also my recollection. ... I don't think centralization has ever been part of the Apache way. I think the cvs-svn experience, and the wiki experience, would suggest that we need to be mindful of the maintenance overhead of not centralising some practical things. I can't see any issue re: the cvs-svn experience and centralization: both environments are clearly centralized, and the migration was done by a small team, from a central repository to a central repository. The moinmoin farms as also very centralized, more aking to vhosts than to separate servers. I'm not really aware of the maintenance overhead of the wikis, but I'm betting that it is not bigger for moinmoin than for cwiki, (I think we have a number of hours donated for the maintenance of cwiki/JIRA) which in addition is proprietary. But thats not the same as centralisation as a principle. And as a final point, don't take this too seriously but... the ASF and the Apache Way has probably been shaped more than we would like to admit by the workflow imposed by CVS. SVN is very similar, but distributed source control has very different workflow which would either conflict with or change the way if adopted. The workflow you do wih most dSCM tools is literally up to you. I have prepared a refactoring for shindig ( http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2 about a 60k global patch, 38 small commits with git) using git, so that I can get familiar with advanced uses of git at the same time. I am (anybody is) free to test it in this branch that I published. What is more, everybody can look into the code with reasonable color diffs. The tool is able to rebase the patch as new commits come in, and it can merge changes inside the context of a file renamed in the first patch. What it is more, I can (anybody can) git diff --stat -p -M synd-rename synd-rename-2 and see what changed between versions of the patch, which already allowed me to detect a merge problem that I introduced when I reordered the commits to get the patch series cleaner to look into. github can't do that, but my local gitweb can An extra goodie is that the git repo with the whole history of the project is smaller (and way faster to access) than a single subversion working copy. And this is true of every project I have tried with git-svn. You might tell me that I could have started a subversion branch to do it, and I'd answer: why is it that nobody does it in the real world? This is really where the workflow of subversion is hurting^Wshaping us. Regards Santiago d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - 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 12:37 PM, Santiago Gala [EMAIL PROTECTED] wrote: 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. That's also my recollection. ... I don't think centralization has ever been part of the Apache way. I think the cvs-svn experience, and the wiki experience, would suggest that we need to be mindful of the maintenance overhead of not centralising some practical things. But thats not the same as centralisation as a principle. And as a final point, don't take this too seriously but... the ASF and the Apache Way has probably been shaped more than we would like to admit by the workflow imposed by CVS. SVN is very similar, but distributed source control has very different workflow which would either conflict with or change the way if adopted. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Hi, On Tue, Feb 19, 2008 at 1:06 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: 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 ??? I'm currently gathering interest [1] about starting an effort at Apache Labs to further explore ideas related to dSCM at Apache. If you're interested, you'll find us at [EMAIL PROTECTED] [1] http://mail-archives.apache.org/mod_mbox/labs-labs/200802.mbox/[EMAIL PROTECTED] BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
FWIW, I quite like both git and mercurial, both give me a better workflow than subversion for a lot of things I work on. Offline commits, local branches, and sane merging are *huge*. The approach to distributed repos is also very nice for folks who do want to maintain a fork elsewhere (forking isn't evil, it is a very good reaction to needing something slightly different which the majority (or the powerful) in the base project doesn't want). Looking forward to trying svn 1.5 branch management, though :-) Being able to repeatedly merge from a branch I didn't branch from will be *huge* (ie, pull bug fixes from release branches without pulling cruft from trunk from whence I branched). I quite accept the practical side of saying svn only as long as no one steps up to manage git or mercurial. Saying though shalt use svn because it is the blessed end-all is BS. Subversion is great, and all, but it also sucks. Some things suck less for different workflows, some things suck more. For one-branch development, svn is awesome. Saying we can have only one because is very weak. Can anyone cite specific problems FreeBSD or Perl have had? -Brian
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: 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: 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: 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: 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]
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]
Re: Subversion vs other source control systems
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. Sorry for butting in this discussion, but I would like to point out that this is only a problem for the standard Subversion client. As an SVK user (another Subversion client) I regularly make use of off-line commits, local mirroring and smart merges. -- 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
Seems like people weren't interested in SVK but solely in Git. Otherwise this thread would have come to an end pretty soon without the need of all the FUD cause I suggested/asked to use SVK some days ago already. It doesn't figure why infrastructure stuff needs to be discussed in such a intensity on the incubator list anyway. Just my two cents ... Noah Slater wrote: Sorry for butting in this discussion, but I would like to point out that this is only a problem for the standard Subversion client. As an SVK user (another Subversion client) I regularly make use of off-line commits, local mirroring and smart merges. - 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 19:02 -0500, Noel J. Bergman escribió: Santiago Gala wrote: I think git-svn abuses the server a lot, as the subversion server is not designed for copying of the whole history. AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator. Dw wrote: I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? - 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 The last one is almost antithetical to how we want people to work. The first few are something that you could raise with the Subversion folks on [EMAIL PROTECTED] 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. And I think it is in scope, as the incubator is an important place for people to learn our ways. 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? Turning your key poing upside down: We should not try to impose our practices using a technological tool, specially when doing so impairs development. If there is a better SCM *for our way of working* raise that on infra@, too. people *against* changes in SCM is blaming a hypothetical introduction of git of breaking the ASF practices 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 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. 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
El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió: 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... outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences with git, and the only downplay of subversion has been the problems with merging, which I think are real. I would only call FUD if there had been mentions, say, to subversion corrupting repositories or similar, and I think those times are far in the past. 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 Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a different 1.4.3 Mandriva rpm). I guess they don't ship contrib stuff. Linus Torvalds discusses extensively work flow processes in http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is mostly right in the fact that distribution is the way to go, and not just because of disconnected operation. In one of the projects I track and patch, I don't commit myself, but I have contributed a number of components and patches and I keep ongoing patches. I would never be able to use svnmerge.py without the ability to create branches or commit. 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 Well, I tried svk, git, mercurial and bzr. I am even using darcs because of some openID code I track. I prefer git, even when forced to use git-svn, to svk. Still, I will try to look into svnmerge.py, I found it here http://www.orcaware.com/svn/wiki/Svnmerge.py 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 Monday 18 February 2008, Paul Querna wrote: 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. All of them are archived. None of them are available to see at: http://mail-archives.apache.org/mod_mbox/ Thus, they look pretty private to me. -- 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]
Re: Subversion vs other source control systems
Daniel Kulp wrote: On Monday 18 February 2008, Paul Querna wrote: 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. All of them are archived. None of them are available to see at: http://mail-archives.apache.org/mod_mbox/ Thus, they look pretty private to me. They are not available on the public web interface, the archives are available to all committers on people.apache.org. private is an interesting choice of words, but I personally don't consider them very private with 1600++ committers having access. Should some or all of them be available on the web interface? I'm not sure, but bring it up on the infrastructure lists. -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Daniel Kulp wrote: On Monday 18 February 2008, Paul Querna wrote: 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. All of them are archived. None of them are available to see at: http://mail-archives.apache.org/mod_mbox/ The EZMLM archives are available to every subscriber. Send a mail to listname-help to get instructions. There's probably also a way to access raw archives, I'm sure the folks on infra can tell you how to get there. The free-for-everyone archives on mail-archives.a.o are obviously only for list where everyone is allowed to see the messages, not for committers-only lists. There is no archive of [EMAIL PROTECTED] there either. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Feb 18, 2008 2:08 PM, Daniel S. Haischt [EMAIL PROTECTED] wrote: Seems like people weren't interested in SVK but solely in Git. Otherwise this thread would have come to an end pretty soon without the need of all the FUD cause I suggested/asked to use SVK some days ago already. the last time i tried SVK, changes would be needed to SVK before it could work with a repository as big as apache - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Feb 18, 2008 1:01 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: the last time i tried SVK, changes would be needed to SVK before it could work with a repository as big as apache FWIW, the partial svnsync changes that SVK would need are present in 1.5. I don't know if the SVK community has picked up on that yet, but SVN 1.5 clients/servers will support it. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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
Re: Subversion vs other source control systems
On Thu, Feb 14, 2008 at 11:25 AM, Ross Gardler [EMAIL PROTECTED] 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. Now, I've never tried this and don't know anyone who has, but thought I'd flag it in case it is relevant. My 2p: I've been doing this recently with qpid, partly because I'm wrangling a large merge at the moment (which it does better than straight svn) and partly because it suits my typical workflow a bit better: cheap local branching means I can hack on something, get interrupted, create another branch to work on that interruption in isolation, commit that to HEAD, rebase the branch from the first thing and pick up where I left off without having to take intermediate patches, revert that out, reapply etc which is what I did before. The initial import is ridiculouisly slow if you take all the history because the asf has one repo for all the projects and it looks at each revision, but you can tell it to only pull history from a certain point. - Aidan -- aim/y!:aidans42 g:[EMAIL PROTECTED] http://aidan.skinner.me.uk/ Almost everything is imitation... The most original writers borrowed from one another. - Voltaire - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Subversion vs other source control systems
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. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
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? /Janne, who does not really know how this bit of ASF works... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
