On 2010-01-15 01:53, Gerrit Voß wrote: > > Hi, > > On Thu, 2010-01-14 at 13:14 +0100, Marcus Lindblom wrote: >> On 2010-01-14 03:06, Gerrit Voß wrote: >>> >>> Hi, >>> >>> On Wed, 2010-01-13 at 10:38 +0100, Marcus Lindblom wrote: >> >>>> However, I'd love to see github.com being used instead of SVN, as it's >>>> much easier to maintain own changes, submit fixes for bugs and for >>>> core-devs to pull& integrate patches. >>> >>> I already mirror the current svn master on github because of the >>> ongoing website problems. Currently I do that manually but I could >>> automate it in the future (e.g. cron scripted once an hour or so). >> >> A post-commit-hook on the svn server would make most sense, no? > > hmm, maybe but the cron job I can control the svn server I can't ;)
You don't have shell-access to OpenSG's svn machine? I thought you did, and I think most core-devs should. (even if it's just a shared account) >>> I'm still a little hesitant to move everything to git as you can >>> do to many weird things to a tree. For now a linear system like >>> svn seems safer. For maintaining own changes it should actually >>> make no difference (git fetch vs. git-svn fetch). >> >> This doesn't seem to be much of a problem in practise, but it probabty >> takes some time for a community to learn a new tool and adapt around it. > > hmm, git in general or git-svn ? Git in general. The main thing is that the committers to the main repo know what they're doing, and they usually do, even if they're not wizards. I'm couting myself to this category, btw. (i.e. if git says "can't push this, changes stuff on remote (use --force to override)", you don't force, you solve the problem properly (by merging). >> As long as there is an offical repo, and backups/clones of that, any >> wierd history things wont happen. And the ones that have push-rights to >> that repo don't do anything stupid there. (They have their own personal >> clones that can change more, but the offical one should never forcibly >> pushed to.) > > in theory yes ;) Just that the possibility is there makes me a little > nervous. I actually have to try how much one can recover once somebody > trashes the tree. You can always replace it with your personal clone (and combining the history from 3-4 active contributors should recover enough), etc etc. One shouldn't loose too much, and a cron-job running clone + rsnapshot should be enough to recover most wrongdoings. There might be a way to disable history-changing pushes completely. >>> As you can merge multiple git source trees into one from my >>> side this should not be a problem. I push both the svn and >>> git repositories from the same master git tree on my system. >> >> Yup. All we need is a 'svn-trunk' branch in git that follows SVN trunk >> (duh :), then everyone can keep their non-merged contributions rebased >> on top of that. > > yes, I saw you found the git tree ;) I'll see I if I can start using it a bit more too. ;) >> The only risk is that contributors' git-repos might become a bit messy >> if the svn-merge-rebase creates new commits, but it should be easy >> enough to manage. > > it should not, I never used merge/rebase between git and svn. All I do > is git-svn fetch; git pull . remotes/git-svn. I only see interesting > things happening if we start making the git tree not just a dependent > clone of the svn but starting to push to it directly ;) And than only > if we get commits simultaneously to both repositories. That's sort of what I meant. With SVN, one needs to always linearize history on top of the latest commit. With Git, not necessarily so. With DVCS:es, one do get simultaneous commits, there's no way around that. The problem is when the backend (SVN) forces linearization, then all other git-users need to move move things about a bit. That is probably not a big problem, but it might complicate things slightly. Contributors & committers just have to rebase incoming changes on top of SVN head before pushing to SVN. A non-linear history looks like this: http://github.com/djmitche/buildbot/network You can see the various tags/branches of features being worked on (in other repos) plus the master (trunk) and the release (release-candiate) branches. The current number of contributors on buildbot makes it possible to run a non-linear history (slightly more ppl than OpenSG) but for larger projects, more rebasing is probably necessary to make the history easier to follow. But, I'm happy enough with having a git-repo that I can fork and contribute to. We can wait with the revolution until everyone's comfortable enough with it (while encouraging and supporting ppl to try git, as I saw you just did). Cheers, /Marcus ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
