I’ve pretty much completed implementing the mechanisms in nautilus and gnome-settings-daemon to implement per workspace wallpapers. I’ve created a short video that shows the current state of the functionality:
As you can see the wallpaper is currently set for whichever workspace the appearance capplet is on.
I’ve put most of the patches (except the gnome-control-center one) into bugzilla:
Its quite clear from the variousdiscussionsrelated to DVCS that there isn’t going to be one clear winner for the choice of VCS for Gnome; everyone wants to use their favourite DVCS. So here’s an idea, why not allow them to?
I think that the deciding factor for which DVCS to use is the quality of the tools that enable interoperability between all the other possible tools. Obviously there is tailor which automates migration of patchsets between different DVCS’s, but I want more native support within the tool I’m using; i.e if I’m using git I want to use “git’s terminology” to “pull and push” from the remote repository. I’ve found git-bzr for interoperating between git and bzr, and similarily there is bzr-git for the other way around,although I’ve not yet had time to see how either of the tools work.
Basically I think that the decision of which DVCS to choose should be based upon which DVCS is the easiest to import into all the others(or at least just the most popular ones!). This makes all the other points regarding speed etc really quite moot so long as these tools work well (In particular I’d like to observe how well they maintain merge histories between the DVCS systems – maybe when I get time in the next few weeks I’ll do some experimenting).
I’ve been trying to automate the updating of my git-svn repos on my server via cron and I’ve finally succeeded in getting something working so I thought I’d share how I’ve got things setup since there seems to be a lack of information about how to do this.
First hurdle was git-svn doesn’t understand about bare repositories – it always looks for a .git directory. Fortunately this is easily solved since git-svn does support the $GIT_DIR environment variable. So I simply set this to . and run the git-svn commands from within the repository directory. So I initialise the repository with the appropriate git-svn init command and then call fetch to retrieve the svn history.
The next problem is that the refs fetched using git-svn are placed in refs/remotes which isn’t cloned when you do a regular git clone. So we need to plugin to the hooks to update the refs after we update the repository; an example script of how to this is provided below (Taken from dscho.git): #!/bin/sh
git for-each-ref –format=”%(refname)” refs/remotes |
sed “s/refs\/remotes\///” |
while read ref
git update-ref refs/heads/svn/$ref refs/remotes/$ref
git for-each-ref –format=”%(refname)” refs/heads/svn |
sed “s/refs\/heads\/svn\///” |
while read ref
if ! git-rev-parse refs/remotes/$ref > /dev/null 2>&1
git update-ref -d refs/heads/svn/$ref refs/heads/svn/$ref
I call the script from the post-update script (which you should make executable by running chmod +x hooks/post-update). This script suffices but doesn’t quite do what I’d like; I’d like the tags to be placed in refs/tags/svn rather than refs/heads/svn, but the script linked will do for me for now.
My cloned repositories are available at http://git.jsharpe.net/, unfortunately I can’t offer the git protocol since my host doesn’t allow it. As I get time I’ll convert more of the Gnome repositories; I’ve only converted the ones I know I’m going to be working on for the moment.