Christian MICHON, 26.01.2009: > On Sat, Jan 24, 2009 at 4:05 PM, Markus Heidelberg > <markus.heidelb...@web.de> wrote: > >> it's not a bug, it's a feature (tm). > > > > I can't find a feature. At least if there is one, then I don't like it. > > But I can see the problems when creating a repo for Vim and your layout > > with unrelated branches is the easiest solution and will work with every > > minor release branch in the same manner. > > ever tried git-cvsimport on the official vim repo ? you'll see it's > linear, and vim7 and vim<7 are actually different CVS repositories.
No, I haven't tried this. > > (2) If there is some parallel publishing, then we have to create "real" > > branches. The most obvious solution is to branch off, when > > parallelism starts. > > > > 5.7.029---5.7.030---5.8---5.8.009 'vim-5.8' > > / > > 5.7---5.7.028---6.0aa---6.0ax---6.0ax.020---6.0---6.0.270 'master' > > > > There we could also create a branch 'vim-5.7' to point to 5.7.030. > > unless I'm wrong, we only have had parallel development between betas > and the official last vim release. Yes, I think so, too. Maybe the example above is even the only parallel development or at least one of few. However, the files with timestamps on the server are my only source of information. And looking at http://vim.cvs.sourceforge.net/viewvc/vim/vim/src/version.c?view=log show that 6.0aa as well as 5.7.029 and 5.7.030 are included in the repository. So no branching from this point of view. > I personally discarded the > alpha/beta releases because it was clouding the overall picture. I'd personally include them for the sake of completeness. We don't have so much history, I don't think it's sane to discard even more. And without the bleeding edge, people will use another method for getting the Vim sources. > > (3) Another solution is to branch off immediately at each release. This > > is the easiest solution that will always work, but we'd get the > > problem, that the 'master' branch will stay on the current minor > > release and the features have to be rebased against the next minor > > release one time. So this isn't really a solution, I shouln't even > > have mentioned it. > > > > 7.0.001---7.0.243 'vim-7.0' > > / > > | 7.1.001---7.1.330 'vim-7.1' > > | / > > | | 7.2.001---7.2.088 'vim-7.2' > > | | / > > 7.0---7.1---7.2 'master' > > I like this solution, but we should have master='vim-7.2' instead. I don't like it, as described above. It looks nice, but it's not useful for development on master. The problem with having master=vim-7.2 is that we need to rebase the master branch for vim-7.3. This would actually be your layout, just with the releases connected with each other. > > I will also adjust the commit message somewhat, e.g.: > > - extract a first single line summary as described by the git > > conventions > > - convert tabs to spaces (that's the reason, why the messages aren't > > aligned properly in your github repo) > > - remove the "Files:" section, it's not necessary within a VCS, --stat > > is much nicer > > I tried to do that, and maybe forgot to change tabs into spaces. I > wanted to keep as much info from Bram original patches. There's no problem with keeping commit message information, while formatting it git-like. > After some thoughts, maybe this need rework: I'll look into it. > > What do you mean by --stat ? git diff|log|show --stat Markus --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
