Sorry to rain on the git love fest going on but ... There are other options. There is no killer reason to use git over the other systems, and the need for a Cygwin base system for windows does raise the bar for Windows users - not everyone will want to have to install and maintain a Unix like command system just to use a source control system. It would be nice to have a reasoned review of the options for Vim development.
Mercurial is widely used, with a possible plus of svn like command interface. Bzr is also good, if not so widely used. IIRC there has been a recent SVN release that supports disconnected working (one of the big selling points of DVCSs) so perhaps that should not be discounted just yet. On 26/06/2008 10:50, Milan Vancura wrote: >> If you see how Bram is handling (well) vim, it has a linear >> development. No branches, No merge. >> When he moves on to the next release, the previous one does not get >> updated patches (it seldom happens). >> >> So actually Bram could do the whole maintainance of vim by just using >> git-gui (graphical interface tcl/tk based). >> >> At this stage, it is so much easier than any of the competing tools. >> It is a fact. > > I think you are right. Vim is a project with needs covered by git 100% and > with > low maintenance work. And the other will profit as well: no more anything like > "which version is your patch against? .435? Sorry, the latest is .465, I can't > test your patch. Rewrite it first.". Or the saga with the floating point > patch: > everyone had to reverse the previous floating patch, then upgrade vim to > current version and apply new version of floating patch. Everything manually. > Argh! This is not what I can call 'easy to use'. > > Git can save all of this. You can: > > 1. checkout to any version and patchlevel you want, at any time > 2. still see patches separately, including their metadata like authors, date > etc. (How can I see all patches between .289 and .301 using CVS? As one big > diff with no sense?) > 3. develop your own patch for longer time easily: > 3.1. you have a branch for the patch local at home, no need to ask any > administrator about rights to create anything on the server > 3.2. this branch is "sticked" to your favorite vim version and patchlevel as > long as you need > 3.3. you can "rebase" this branch to another (typically current) patchlevel of > "upstream" vim and see conflicts easily (good to do before publishing the > new version of the patch to vim-dev mailing list) > 4. you can publish this branch to other people for collaborative work on the > patch, for testers etc. All they need to do is to add your branch to their > tree. No manual reversing, applying, looking for patches at mailing lists. > 5. you still can apply patch coming from the mailing list, and easily: you > simply checkout to the state the patch requires and apply it. And to > the new branch, if you want. For example to not loose your own version of > the patch. Merging both branches in the future is easy with git. > 6. get graphical frontend showing all branches, merges etc. (git-gui or gitk) > 7. maintain the branch of your favorite distro's patches to be able to update > vim and not to loose the advantages of your distro > >> I intend to re-build a clean git tree for vim (don't expect it sooner >> than next week). I will be able to show graphically why it would be >> easy to maintain vim with git. > > Sure. It will be the best how to show all of the advantages. Great idea, > Christian! > > Milan > > > Mike -- The Martian canals were the Martians' last ditch effort. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
