Re: [CMake] Re: Migration to subversion
Rodolfo Schulz de Lima wrote: > That's great news. Since I've never been involved in a CVS -> SVN > migration, I couldn't help so much with it. Also, excuse me for assuming > you weren't using svn and trying to sell it to you :) Before you switch to svn please use git. It's much better than the pain of cvs or svn. > > Regards, > rod -- andreas > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Dec 22, 2007 6:48 PM, Andreas Schneider <[EMAIL PROTECTED]> wrote: > Rodolfo Schulz de Lima wrote: > > That's great news. Since I've never been involved in a CVS -> SVN > > migration, I couldn't help so much with it. Also, excuse me for assuming > > you weren't using svn and trying to sell it to you :) > > Before you switch to svn please use git. It's much better than the pain of cvs > or svn. Mozilla is migrating to Mercurial. They rejected git; I forget why. It's early days for peer-to-peer source control, but based on my Darcs experience, in principle I'm a fan. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
And what about Bazaar (the tool used by Ubuntu/Caronical) ? http://bazaar-vcs.org/ Regards, Félix C. Morency Message: 2 Date: Sat, 22 Dec 2007 18:53:10 -0500 From: "Brandon Van Every" <[EMAIL PROTECTED]> Subject: Re: [CMake] Re: Migration to subversion To: cmake@cmake.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 On Dec 22, 2007 6:48 PM, Andreas Schneider <[EMAIL PROTECTED]> wrote: > Rodolfo Schulz de Lima wrote: > > That's great news. Since I've never been involved in a CVS -> SVN > > migration, I couldn't help so much with it. Also, excuse me for assuming > > you weren't using svn and trying to sell it to you :) > > Before you switch to svn please use git. It's much better than the pain of cvs > or svn. Mozilla is migrating to Mercurial. They rejected git; I forget why. It's early days for peer-to-peer source control, but based on my Darcs experience, in principle I'm a fan. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On 12/22/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > On Dec 22, 2007 6:48 PM, Andreas Schneider <[EMAIL PROTECTED]> wrote: > > Rodolfo Schulz de Lima wrote: > > > That's great news. Since I've never been involved in a CVS -> SVN > > > migration, I couldn't help so much with it. Also, excuse me for assuming > > > you weren't using svn and trying to sell it to you :) > > > > Before you switch to svn please use git. It's much better than the pain of > cvs > > or svn. > > Mozilla is migrating to Mercurial. They rejected git; I forget why. > It's early days for peer-to-peer source control, but based on my Darcs > experience, in principle I'm a fan. > My 2 cents. Distributed is the right way to go in my opinion. Git and Mercurial look like they have the most mindshare. I believe these will be the two dominant players by far in the coming years. I think Linus pointed to some scalability problems in Monotone and I think others have pointed to performance and memory usage problems with Bazaar (OpenSolaris?, Mozilla?). I haven't seen much mention of Darcs except for the 'dreaded exponential merge problem' and being written in Haskell making it harder to port. I would recommend going with either Git or Mercurial. However, the Windows story is currently pretty minimal with Git. I think Cygwin is still the best supported way to use Git on Windows, though I've read there is now a working Msys port. However, both of these options will be unacceptable to most Visual Studio users. With the CMake audience and funding being heavily slanted towards Visual Studio, I would say Git in its current state would be a bad decision for CMake. Until something like a 'TortoiseGit' appears and becomes usable/matures, I would rule out Git. That leaves Mercurial. They do seem to have a TortoiseHg with a 'batteries included' installer which makes it much more viable for the Windows story. >From a user standpoint, Git and Mercurial are almost extremely similar in core interface and feature sets. Most of the differences seem to be implementation details. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 4, 2008 10:17 AM, E. Wing <[EMAIL PROTECTED]> wrote: > > I think Linus pointed to some scalability problems in Monotone and I > think others have pointed to performance and memory usage problems > with Bazaar (OpenSolaris?, Mozilla?). I don't know what they tried before, but Mozilla is a Mercurial shop now. > I haven't seen much mention of > Darcs except for the 'dreaded exponential merge problem' and being > written in Haskell making it harder to port. My $0.02 is Darcs is easy to use. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On 2008-01-04 07:17-0800 E. Wing wrote: My 2 cents. Distributed [version control system] is the right way to go in my opinion. I don't completely agree. Centralized repositories have proved useful for lots of software development projects (e.g., the 160,000+ free software projects at SourceForge). Of course, centralized repos don't work very well if projects (such as the Linux kernel) have huge numbers of active developers, but most software projects (such as CMake) will never have more than a handful of active developers, and for such projects a centralized repository makes a lot of sense. Thus, it is probably a given that CMake will always use a centralized repository. I assume that does not rule out git or Mercurial. For example, from the git-svn crash course at http://git.or.cz/course/svn.html, it appears that git has the capability to use a centralized repository (the so-called bare repository), and I presume that is the case for Mercurial as well. So the choice between cvs, svn, git, and Mercurial really boils down to how impressed the CMake developers are with the particular implementation of a version control system with a centralized repository. My own personal experience has been I used CVS for years (at first because that was all that was available at SF, but then after they deployed the svn alternative there it was just inertia even though there were many aspects of cvs I did not like). However, last year I participated in one project that used svn, and that nice experience convinced me rather quickly to switch all my projects to svn because cvs just sucks in comparison with svn. Currently, I am almost completely satisfied with svn, and I think it would be an excellent choice for CMake as well. However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Mike Jackson wrote: > http://www.youtube.com/watch?v=4XpnKHJAok8 > > Git - straight from Linus. I have this strange preference for my own voice and personality :-) http://video.google.com/videoplay?docid=-7724296011317502612 http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Alan W. Irwin wrote: > However, I admit to having no development experience with git or Mercurial. > Is there anything compelling (e.g., fewer bugs, better documentation, more > useful features aside from distributed?) about either over svn for > projects like CMake that use a centralized repo? A significant difference is completely offline operation. With a centralised tool, by definition you can't commit if you're not on the network. With a distributed tool, committing changes is decoupled from sharing them. As you surmise, you can agree to use a central repository with a distributed tool, but it's a matter of preference and convention, not something forced upon you by the tool designers. http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
http://www.youtube.com/watch?v=4XpnKHJAok8 Git - straight from Linus.. Kinda long but interesting.. as long as you can get past Linus' personality. Mike On Jan 4, 2008 4:11 PM, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote: > Alan W. Irwin wrote: > > > However, I admit to having no development experience with git or Mercurial. > > Is there anything compelling (e.g., fewer bugs, better documentation, more > > useful features aside from distributed?) about either over svn for > > projects like CMake that use a centralized repo? > > A significant difference is completely offline operation. With a > centralised tool, by definition you can't commit if you're not on the > network. With a distributed tool, committing changes is decoupled from > sharing them. > > As you surmise, you can agree to use a central repository with a > distributed tool, but it's a matter of preference and convention, not > something forced upon you by the tool designers. > > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > -- Mike Jackson imikejackson _at_ gee-mail dot com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 4, 2008 3:50 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > On 2008-01-04 07:17-0800 E. Wing wrote: > > > My 2 cents. > > > > Distributed [version control system] is the right way to go in my opinion. > > I don't completely agree. Centralized repositories have proved useful for > lots of software development projects (e.g., the 160,000+ free software > projects at SourceForge). Of course, centralized repos don't work very well > if projects (such as the Linux kernel) have huge numbers of active > developers, but most software projects (such as CMake) will never have more > than a handful of active developers, and for such projects a centralized > repository makes a lot of sense. Why? Other than it's what you're used to. When I was doing Chicken Scheme, we had very few people banging on the Darcs source repository, but nevertheless it was useful to our work. Typically we could just work past each other and not worry about merges. > Thus, it is probably a given that CMake > will always use a centralized repository. You haven't even begun to prove a "thus." What is so important about being centralized? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
- Original Message - From: James Mansion Date: 1/4/2008 3:38 PM > Gonzalo Garramuño wrote: >> In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. >> > Does git work on Win32? Pretty well, I've found, using http://code.google.com/p/msysgit/ I've spent the past couple weeks looking (again) heavily into Bazaar, Git, and Mercurial. Let me see if I can recap some of my positive and negative experiences, bearing in mind I'm a Windows user. Let me start by saying they all seem to work reasonably well and are all distributed. Bazaar: * Pro: I love the lightweight checkout support from a central repository. For games with gigabytes of assets, storing the history locally for all those assets is often unreasonable. Lightweight checkouts provide a direct connection to the server and work almost exactly like Subversion/Perforce. * Pro: For a checkout, I can bzr unbind it and commit locally only. Nice. * Pro: Bazaar has a smart server built in. I set it up and had it running over an Stunnel client certificate connection in no time. No need to set up an SSH server for pushes! Yeah! * Pro/Con: Branches are directories and can be switched in place or used as a separate tree. * Con: No authentication for the smart server. Blech. * Con: Bazaar for Win32 requires a patch or initial large bzr branch operations fail. Ironically, I got the one line patch from their own bug database. It just isn't integrated yet. * Con: Initial bzr branches take much longer than Git. * Con: No visuals during branch, push, or pull operations to show me how the network transfer is going. * Con: Bazaar seems to eat 100% of the CPU time when performing its operations. * Con: No submodule/subproject support. Git: * This one is much different than any other version control system I've used. This may be good or bad. I don't know. My curiosity is piqued enough to fight things like the SSH support. * Pro: When cloning a local repository, you can get the secondary repository to refer to the heavyweight content in the initial repository, thereby saving disk space. * Pro: As far as GUIs go for all 3, QGit is one of the better ones. It still doesn't compare to a complete tool like P4V/P4Win. * Pro: Has submodule support built in now. This means I can put n different repositories in a hierarchy and have it mostly treat the whole tree as one repository. There is still some work to be done here, but it is definitely a big deal. * Pro: Shows progress on clones. * Pro/Con: Branches are named and switched in place. * Pro/Con: Has the ability to create a shallow clone without all the history. Unfortunately, the clone is mostly useless for development. * Con: The local repository clone space savings only applies to local repositories. There is no equivalent of the Bazaar lightweight checkout from the server repository. * Con: Requires an SSH daemon to push data. I just barely got this going (through copSSH) with the replacement git-shell, because I don't want people to have shell access to my machine. Locking down user permissions and directories on a Windows box stinks. I've got to see about setting up the SSH authorized keys. * Con: msysgit doesn't come with git-daemon, but git-daemon is for read-only, pull access anyway. Mercurial: * Pro: Seems reasonably fast. * Pro: Has an access control list extension. * Pro/Con: Branches are named and switched in place. * Con: No lightweight clones of repositories. Unix hardlinks don't count. * Con: The hgwebdir.cgi was a pain to set up, and it doesn't support client certificates over https. Boo! * Con: I can't figure out how to get the SSH support working. It just hangs, and hg -v --debug is not that helpful. * Con: The submodule support through the Forest extension feels incomplete. svk: * Pro: Has an ultra cool svk sync -s HEAD command that starts your repository from the latest with no back history. If I sat down with this longer, I'm sure I could really flesh these lists out. Josh ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
James Mansion wrote: Gonzalo Garramuño wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? Yes, but not as well as on Linux. There's two ports of it. The cygwin port which should be more or less in sync with Linux but works very slow. It is also probably not that well suited for windows projects, as I believe no CR/LF conversion is done. The MinGW port which is much faster and already pretty functional (look for msysgit, IIRC). It also handles CR/LF conversions. This is likely the one you want to try. Some advanced functionality may still be missing as it is not a complete project yet. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Joshua Jensen wrote: > * Con: Requires an SSH daemon to push data. I just barely got this > going (through copSSH) with the replacement git-shell, because I don't > want people to have shell access to my machine. Locking down user > permissions and directories on a Windows box stinks. I've got to see > about setting up the SSH authorized keys. It is possible to use webdav for pushing to git, but it isn't recommended. http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Mike Jackson wrote: http://www.youtube.com/watch?v=4XpnKHJAok8 Git - straight from Linus.. Kinda long but interesting.. as long as you can get past Linus' personality. Here are my two cents: I actually held Linus opinion in rather high regard until he went berzerk on how bad Subversion is. *Please* don't take everything Linus says as The One True Way to version control heaven. Subversion does not fit Linus needs (understandably), but that does not mean the DVCS is suitable for everyone. Those of you who haven't already read "Version Control and 'the 80%'" should do so (http://blog.red-bean.com/sussman/?p=79) *before* forming your opinion on centralized version control. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
At 1/5/2008 09:24 PM, Jesper Eskilson wrote: Those of you who haven't already read "Version Control and 'the 80%'" should do so (http://blog.red-bean.com/sussman/?p=79) *before* forming your opinion on centralized version control. Interesting read, especially the paragraph about: "In a nutshell: with a centralized system, people are forced to collaborate and review each other's work; in a decentralized system, the default behavior is for each developer to privately fork the project.". Anyway. Before flaming each others, please bear in mind that the decision remains in our hands, at Kitware. I won't speak for Bill or Ken on this specific issue, but the *vast* majority of our projects is hosted on CVS, and the rest on SVN. There is only a handful of contributors to CMake, and one of the most efficient distributed technology they use is actually known as "walking to someone's office"; *if* the CMake repository ever switches to a different versioning system, I would be personally surprised it is a distributed one. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 5, 2008 5:58 PM, Sebastien BARRE <[EMAIL PROTECTED]> wrote: > At 1/5/2008 09:24 PM, Jesper Eskilson wrote: > > >Those of you who haven't already read "Version Control and 'the > >80%'" should do so (http://blog.red-bean.com/sussman/?p=79) *before* > >forming your opinion on centralized version control. > > Interesting read, I found the 80/20 formulation kind of obnoxious. People who regularly swallow the intricacies of Java and C++ for a living, are incapable of swallowing DVCS concepts like "push" and "pull?" Baloney. It's a question of willingness to do so, or mandate to do so. When there's no will, and no mandate, then techies love to bitch and moan about any perceived inconvenience or learning curve. > especially the paragraph about: "In a nutshell: > with a centralized system, people are forced to collaborate and > review each other's work; in a decentralized system, the default > behavior is for each developer to privately fork the project.". I'm not impressed by any of the FUD I've heard about DVCS. There's a consistent theme of assuming that technology implies policy. In DVCS, it doesn't. The idea that developers privately fork projects "by default" is completely silly. You think I had time to maintain my own private version of Chicken Scheme? Heck no. Anybody who's really against DVCS should get some experience with it before passing judgment. > Anyway. Before flaming each others, please bear in mind that the > decision remains in our hands, at Kitware. Personally, I refute the case that there's anything deeply wrong with DVCS that should bar its use. Darcs never got in my way. Is there anything *compelling* about DVCS for the CMake community's needs? I don't know. At present, I don't care. I've yet to do any work in the CMake source pool; I just file bugs and edit the wiki. Mozilla is the study for Mercurial. It's still early days for them, they're in transition from CVS. I suggest watching them, to see what benefits they gain. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Jesper Eskilson wrote: > Those of you who haven't already read "Version Control and 'the 80%'" > should do so (http://blog.red-bean.com/sussman/?p=79) *before* forming > your opinion on centralized version control. That article mixes some reasonable points with a good dose of nonsense, so please apply your careful reading filters to it. There was a lot of followup in the blogosphere to it, much of which is worth tracking down. http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: Migration to subversion
Alan W. Irwin wrote: developers, but most software projects (such as CMake) will never have more than a handful of active developers cmake already has about 10-20 or so developers (if you consider all the .cmake module contributions). People with commit access, however, are much fewer right now. I assume that does not rule out git or Mercurial. For example, from the git-svn crash course at http://git.or.cz/course/svn.html, it appears that git has the capability to use a centralized repository (the so-called bare repository), and I presume that is the case for Mercurial as well. Not really. Both git and Mercurial are always distributed. You can have one "official" repository but you cannot prevent people from cloning it. However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? See Linus presentation at google (available on youtube). But basically, with git you get: * Faster and smaller repositories. A git repository will often be 1/3rd of an equivalent cvs or svn one. * git guarantees that what you put in the repository is what you get out. All commits are SHA1 verified. CVS and SVN have no verification. If disk corruption happens or a malicious user fakes a file or screws up, say, the ,v files, you can get garbage out without anyone noticing. * git offers two apis (one for high level user access and one for low level admin/script access similar to using tricks in cvs like hacking the ,v files). * Branches and merging are native to the repository. Both can be done in linear time (and probably) with much less chance of conflicts. * Distributed. You can work with the repository without being connected (on a plane or laptop, for example) and then merge later. * Distributed allows you to much more easily mix and match from several repositories of trusted persons, to create your own flavor of code. For example, Linus is not an expert in networking, but he can easily fetch and merge network changes from other developers that are, once they verified the code (thus, reducing the amount of work *he* has to do on things he is not really an expert on). A central repository makes it much more easy for the changes of the two developers to overlap or screw up the build of the other person while developing. Or the developer just has to "never commit, until all your tests pass and your changes are done". * git offers bisect options in linear time. It becomes trivial to find a line commit that screwed up something. There's nothing like that on CVS or SVN, where it has to be done manually. And even then, it is not linear. * git patches can be created to be easy to email for those that have no write access. * git has proven scalability (for both git and the kernel, probably some of the largest per day/month commit base of any known projects). With Mercurial you get the same except faster and smaller and only a single api. It is at least 40% slower than git in my (short) experience. Monotone offers better verification but much, much slower performance. In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: Migration to subversion
Gonzalo Garramuño wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: Migration to subversion
On 2008-01-04 22:38- James Mansion wrote: Gonzalo Garramu�o wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? As already mentioned earlier in this thread, git is available for Cygwin (see http://cygwin.com/packages/git/), and for those who prefer the MinGW development environment, I just now discovered a git version that apparently can be built using MinGW (see http://repo.or.cz/w/git/mingw.git and http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master). Also, Mercurial (mentioned as another alternative to git on this thread) is python-based so it should run on just about any platform. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
