Subject: Re: madwifi git repository (Was: DFS status)
Newsgroups: gmane.linux.drivers.madwifi.devel
Date: 2008-07-17 23:15:48 GMT (25 weeks, 1 day, 5 hours and 1 minute ago)
Hi, On 18/07/2008, at 1:03 AM, Georg Lukas wrote: > > ACK. I think the motivation behind the non-topic changes was to have a > branch where things can be tested before putting them into trunk. This > could be mitigated by using personal repositories and letting other > people fetch from them. I'd like to see this route taken - it's pretty much the whole point of decentralised version control :) > > >>> We could create a git mirror for those who wants personal branches, >>> but topic branches are not personal branches. >> Good idea - a read-only git-svn mirror that we can git-clone off for >> personal local working branches would be great. Have the git-svn >> mirror fetch changes from svn every hour or so. I already have a >> similar set up locally and it works a treat. > > I'm also using git-svn for madwifi, and I love it. However, I do not > see > too much use in creating a read-only git clone of the repository, > besides of providing an option to accelerate the initial checkout and > encourage users/developers to get familiar with git (which is an > important point). > The reason for a read-only git repository would be, as you say, to get everybody used to using git tools. It's pretty hard to go back to using straight SVN once you've got a real feel for what git can do. Making dcommit work would be nice though, and if it's possible, which it seems to be thanks to Felix's script, that would be a nice touch. Migration to a native git repo would be nice, but we'd have to agree on a workflow: 1) Completely decentralised, there is no "official" source 2) Centralised CVS-style development with personal branches maintained as local branches by developers. Developers end up pushing their results directly into the "official" tree. 3) Linux kernel style development. Option 1 doesn't really help. Option 3 introduces a huge amount of administrative overhead, but it also results in the least amount of on- going breakage in the official tree. Option 2 seems like a nice middle ground, as long as we can agree on the use of topic and personal branches. > I am also not sure if it is possible to dcommit from such a cloned git > into the main svn. > > I would like to see the main madwifi repo converted to git in a > reasonable time frame, but it requires several things to be done > first. > > If there is consensus about changing the repository, we should make a > list (on the wiki or as a task in trac?) of things which have to be > completed for such a heavy change: > > * merge -dfs back into trunk (will not be easier with git due to the > already done untracked merges) > > * set up the read-only git clone (it probably could be auto-updated > using a hook in svn) > > * make sure all madwifi developers with commit rights are familiar > with > git > > * deploy trac 0.11 and test if it cooperates well with git (might be > tested on the read-only git clone of the current svn) > > * see if we can port the ticket history from trac-svn to trac-git. > > Other contributions to this list are welcome. > A point to keep in mind: We use svn externals for ath_info which git doesn't support. Cheers, -- Scott Raynel WAND Network Research Group Department of Computer Science University of Waikato New Zealand ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/