Frans Pop wrote: > crazy > butt ugly > insane > reeks > can't be bothered to do a proper migration Well, I think we know how you feel about this. But, the presence of the above words makes it much more difficult to write a friendly, reasoned, objective, non-defensive reply. > Given the team meeting this evening I guess this is my last chance to > comment. The main reason I haven't so far is that I find myself simply > caring less and less, but well. If the above words tell me anything, it's that you must still care, FWIW. > I really have only one argument against the switch to git: the splitting of > the repository into multiple separate repositories. IMO that split is a > huge loss. If there were really huge advantages *for D-I as a Debian > project*, I could imagine accepting that loss, but IMO there are no > significant advantages. > > Debian Installer is *one* (upstream!) project with components that are > sometimes tightly related, which should have a *single* (either central > or decentral) repository It's more complex than that. We have important d-i components that are stored in other VCSs (ie, linux, libc). Other things are uncomfortably grafted into the svn repository, despite having broader applications to Debian as a whole (busybox in /people, live-installer being shared with Debian Live, cdebconf being planned to be part of Debian base, os-prober being used by grub2, flash-kernel producing a deb as well as a udeb, etc). d-i is generally loosely coupled, and melts into Debian around the edges. > The way D-I is managed as a project and most work on D-I does IMO not > require distributed SCM We're using distributed SCM every day between git-svn and people posting patches to this list for review. What we lack is a unified distributed SCM platform, and I think we're suffering because of that in ways that may not be obvious. > and for the situations where either distributed > or offline work is desired, git-svn is IMO a more than adequate solution. > > Let me also make clear that I have very little against git, except that it > has a *lot* steeper learning curve than subversion. git-svn is harder to learn than either svn or git. > In the proposal a few things besides the manual and master PO files are now > weirdly kept in a "master" SVN repo: > - scripts > - kernel/massbuild* > > So for example when there is a kernel update, we'll now have to do an svn > commit to update the massbuild.versions file, followed by separate git > commits to update the various kernel-versions files. Of course these could be put into some git repo, but it's not clear to me what such a repo should be called. (It didn't help that kernel/massbuild is not located in scripts or kernel-wedge.) > Sure, 'mr' is being proposed as "the" solution to keep it all hanging > together. I somewhat remember the announcement of 'mr' as a useful tool to > keep repos for *unrelated* projects up-to-date. Emphasis on *tool*. Tools can be used for more than one purpose. > purpose, but promoting it as the glue for the proposed D-I setup is just > crazy. It means that developers will now have to choose between *three* > sets of commands (mr, git and svn) to do stuff as NONE of them will be > appropriate in all situations. Whereas, my experience with working with d-i is that sometimes I used git, sometimes I used git-svn, and sometimes I was not able to use git-svn for certian types of changes (moving directories?), and had to fall back to svn; none is appropriate in all situtations. > Here's a few things that currently are possible using git-svn (or with any > solution that keeps D-I as a *single* source repository) that will no > longer be possible with the new setup. > - git grep across repo (mr is no option) mr could actually be taught to do this, although svn's lack of a 'svn grep' means it would take a few lines of code. > - using gitk across repo (mr is no option) gitk in a git-svn repository must look very boring, given the small, flat branch structure. Anyway, something seems off about using gitk as a reason *not* to switch to git. > I've had *many* occasions > where a change required interdependent changes in multiple components, for > example in multiple partman components, or in pkgsel and di-utils, or in a > component and in the D-I build system. > If D-I is a single repository I can simply create a new branch and work > there. If the components are split up, I will continually need to create > branches, make sure that I'm in the correct branch for the current > component when changing directories, etc. d-i's svn repo tends to get very few branches of the whole tree, and those branches tend to be hard to work with. The only active such branch is for kfreebsd. (Which actually only currently touches 5 packages, although it is hard to figure this out using svn!) Local branches in git-svn repos cannot by published to others as VCS-accessible branches; one easy way to accomplish a similar thing with git is to copy the whole d-i tree, commit to master, and never push. (Or, if you, like me, feel that keeping a local branch in git-svn is just asking to lose work when a disk crashes, you can push the resulting git repos to your ~/public_git/ on alioth.) Git will, of course, make managing branches that only affect a simgle component much easier than svn does. It seems better to optimise for this common case than continue to notionally support the uncommon case of a real, published, whole-tree branch. > And I will no longer be able to commit related changes in different > components as a single commit. You forgot to say why it is important to do this, FWIW. Of course, if the components are not all included in d-i svn, you already can't do that. It's been not uncommon for me to need to make a commit to d-i and a commit to tasksel for a single logical change, for example. > When the migration from CVS to SVN was done at least nothing was lost. (Aside from some screwed up branches and tags I noticed when looking at the CVS history when doing the git conversion...) > This migration simply drops a lot of work that was done in the past > (such as obsoleted components) All obsoleted d-i components are present in their own git repos in the attic subdirectory. > > On Thursday 13 August 2009, Joey Hess wrote: > > > Other whole-tree tags and branches are not included. These include > > > sarge, etch, and lenny tags and branches, and old tags like rc1, rc2, > > rc3. > > As mentioned above: why not? I'd think especially the release branches are > essential. Prior discussion about this point seemed to come to the consensus that, in cases where we do currently use the whole-release branches in svn, we could just as easily branch from the tag for the stable release version in git. Eg, to work on stable's version of anna, `git checkout -b stable 1.33` > It also means you do not have tags for versions uploaded to testing > or stable. In git we have tags for every version of every package ever uploaded. Unless these packages were uploaded to stable without being properly tagged.. > > I am not currently filtering out the da.po miscommits. Leaving them in > > increases the total git repo size by 5 mb. If they are removed, there > > are two ways to do it, that affect tags made during the problem > > period in different ways: > > > > 1. Keep da.po miscommits in the tags. This bloats the git repo size > > about the same amount, and means that those tags will not be > > connected to the rest of the repo history. > > 2. Drop the bad da.po changes from everything, including tags. That > > would mean that 17 tags don't match what was originally committed > > to svn, but would otherwise work great. > > IMO that cleanup should still be done _before_ a migration. That should > give a clean migration while keeping correct history. That cleanup has still not been done after many months (and makes using git-svn painful in the meantime BTW). Meanwhile, the git conversion can easily deal with the issue. And the result of choice #2 is identical to the result of doing the svn cleanup first and, in that cleanup, deciding to not bloat the tags with the bad da.po files. -- see shy jo
Attachment:
signature.asc
Description: Digital signature