Working with branches after 4.6

Brian J. Tarricone bjt23 at cornell.edu
Thu Feb 19 19:48:37 CET 2009


Nick Schermer wrote:
> Developers (!),
> 
> Jannis had this nice point in his fosdem presentation that we should
> work more in branches, esp. for large (project wide) changes so
> trunk/master is not 'broken' for a long time and thus allowing us to
> do releases more often/easy because the main branch is always in good
> shape (the idea is good *wink*).

I dunno about you, but I never leave my trunk in a broken state ^_~.

> An important aspect of this is a vcs that does branching and merging
> nicely and I think we more or less agree git is the way to go.

Yeah pretty much.  I was going to wait until 4.6.0 before bringing all 
this up, but it seems some people are impatient, so... :-P

> I also heard rumours Brian wants a svn clone running along side? Why?

This is just a nice-to-have for people who want to check out the source 
tree using tools they're familiar with.  It would be read-only and 
hopefully require close to zero maintenance.  Git is not exactly 
user-friendly and has a rather steep learning curve.

> What to do with the goodies and archive?

If we're going to migrate to a new VCS, we're doing everything. 
Maintaining the infrastructure for 2 different VCSs isn't something I'm 
interested in doing.

> What are the permission problems/limitations?

Git doesn't do fine-grained inside-repo permissions by default.  We'd 
need to write (or find and modify) pre-commit hooks to (for example) 
allow translator access to the po dirs but nothing else.  This isn't 
super hard, I don't think, but it's something we'd need to do.  Bonus 
points if it can use our existing svnperms.conf file for all the 
permissions regexes.  If not, someone needs to redo all that stuff.

> Anything else?

A lot.

1.  I18n scripts need to be rewritten to use git instead of svn.
2.  Need to set up new post-commit hooks for commit mails.
3.  Need to set up new post-commit hooks for CIA.
4.  Need to add the repos to cgit.
5.  Need to migrate all the current git.xfce.org stuff to the new 
infrastructure (we're not going to use the same thing for xfce).
6.  Need to do a bunch of test svn->git migrations and verify the 
integrity of data and history.  This includes branches and tags.
7.  Need to migrate svn:ignore to .gitignore.
8.  Need to rewrite snapshot generation script.
9.  Need to redo any buildbot integration botsie has started.
10.  Need to redo i18n statistics gathering script.

And there's a lot more... this is just off the top of my head.

There's also an automation/management issue.  Right now, for example, 
creating a new goodies repo is as simple as:

svn mkdir https://svn.xfce.org/svn/goodies/$repo/{trunk,branches/tags}

... and then adding the repo to /modules so it gets picked up by the 
i18n stuff.  For git, you'd need to:

1.  Create a new repo on the server somehow.  Naively, this needs to be 
done by someone with root access on the server without some sort of web 
frontend.
2.  Copy in the pre-/post-commit hooks.
3.  Set up permissions in the config file.
4.  Add the repo to cgit's config.
5.  Export the repo via git-daemon.
6.  Add the repo to be checked out via whatever i18n script we use.
7.  ?? I'm sure there's more I'm forgetting.

Right now, I'm mainly watching how GNOME is doing this (see 
http://live.gnome.org/GitMigration).  Since there are very few of us, 
and many of them, I was hoping to leverage a lot of their work.  So it 
would probably be a few months before we got this done.

	-brian



More information about the Xfce4-dev mailing list