Vincent van Ravesteijn <v...@lyx.org> writes: >> >> >> > up to know it was solved via commit hooks on lyx.org server. >> >> > i guess we could proceed with lyx.org again, but it would be >> >> > substantialy more work than gitorious. do you feel like working on it? >> >> > (maybe Lars can help?). >> >> >> >> I can. If I am to do anything with this I am more likely to go the >> >> gitolite way. >> > >> > Lars, Are you willing to set up a git repo on our server ? Gitolite seems >> > interesting indeed. I will have a closer look on it. >> >> I can look at it. Pity that the server uses debian, I am a lot less >> familiar with that. > > | It would be nice if you could try anyway. I'm sure you'll be able to manage.
Before I try, I'd like to do the conversion proper and see if everybody is comfortable with the result. Btw. Are still interest in me doing this? (gitolite and svn -> git conversion) > > > >> >> You really do not want to have all devvies pushing commits. >> >> Make a small cabal of people to do this instead. >> > | Hmm.. the LyX devvies are a small cabal of people.. right ? yeah... >>> This seems in general to be the policy, but I'm not sure I want to have >>> too many restrictions. The idea was to let all devvies push into their >>> own branches > >> I don't think that is a good idea. Developers should have their own >> _repos_, at the server. >> > | That could be a possibility. I didn't want all developers to create a fork | on github | or gitorious or the like. However, I don't know how things will be when all | devvies | have a repo on the the server. > | Another thing I don't want is that we have to depend on one person to do | the merging. If this person does not have time for a while, other people | might | get angry and demotivated if their features are not pulled into trunk-devel | for | some time. That's why I proposed that people with svn commit rights would | be able to push themselves and merge their branch into trunk-devel. A script | will then easily pick up the branch and will put it in the process which | will | eventually get it to merge into trunk-stable. Note that the general (distributed) git model is a model where every developers have two trees: one private one, and one public one. The devloper uses the private one for personal development, branches etc. And uses the public one for sharing his work. (a developer can of course orgainize his work in multiple repos.) In a project there will be a (one or more) special repos. Being the pristine upstream repo, the master that all others are originally based on. > >> (merging to the main repo will not be any harder because of that, but >> a lot of cruft can >> be kept out. (after all deveopers come and go)) >> >> > and >> > let them merge it into trunk-devel (which is a temporary branch). I will >> > then merge >> > it into trunk-stable. >> >> I must admit that I don't see the point in having two trunks. (I see a >> real danger in one being tested all the time, and the other almost not at >> all.) >> | The idea is that all features that are well tested and seemed to be ok are | merged into the trunk-stable branch. In theory, it should not be needed to | extensively test this branch because all separate features have been tested | before. Secondly, it will be attractive to much more people to test | trunk-stable | as it won't have serious problems from time to time. > >> Sure several release branches might be ok, (even if I'd even then >> would prefere multiple repos) | The trunk-stable branch will be basically the "release branch". Well.. no I think. It will be where you can cut releases from, but the release branch will either have to be a separate repo (eg. linux kernel stable repos), or a branch. >> In all things git one really should look hard at the linux kernel >> development model and see what >> would fit and would would require modifcations. >> > | I'm looking at the Git development model and adapted it to our needs | and to the feedback I got on the devel-list. I think I must revise some of my thoughts. I think that you should intially do deviate too much from the svn model that your are familiar with, and rather enhance that model when you get experience with git and begin to see benefits and opurtunities in useing a more "gitty" model. Anyhow, I can work on getting this to happen.
