You mean a two way sync, so that all changes made in github are synced back automatically to the correct branches in svn even if they are based on external forks etc? I dont think that this will work reliably.
you are right. a sync in both directions would be too unreliable and very complicated to setup. I would only go for a periodic pull to keep the GitHub repo up-to-date
The main problem with using git and svn is that git will rewrite its history when pushing the changes to svn. A one way sync from svn to git would be an option. Git users can provide patches easy enough if they would want to. I'd prefer the ispconfig organization to setup a github organization but I could easily set up the svn sync in a cronjob on my server. Or you can do that yourselves too I'm vStone on github, feel free to poke me for any git relates issues.
You can also map svn author/usernames to proper Names with email address, but that would require somebody to provide that list.
ISPConfig has already a github account and we might test it in future. At the moment we use svn only and all devs interested in contributing to ispconfig can get access to our svn server.
@vStone: How about setting up the GitHub repo with sync from the SVN (one-way)? I would really like to fork the tags to create install packages for my servers with internal settings (templates, etc.) from the release packages. I do not see an "ISPConfig" organization on GitHub. You could create it if it really is not existing and later port it to Tills account if need be.
I have setup a first svn2git mirror and would be happy to setup one for the ispconfig repo. If you like I could push it to https://github.com/ispconfig
Please don't. I really prefer to stay with svn and I am not interested in digging into git to be able to continue contributing to ispc.
No I didn't as I do not have any github projects or repositories I use. Still I would never use github for own projects as I want to have (full) control of the repository server I use for my projects.
I agree with that.. I only use github to work with others projects, personally I use gitolite for my companies internal development to secure who has access to what. However, another option if someone wanted to create something like github and perhaps an easier way to administer would gitlabhq (http://gitlabhq.com/)... In any case, exact options as to what one would use for what is up to the end person who sets the repo up, be it using gitolite, github or gitlab.
Adding my 2c... For the ocPortal project, we switched over from running our own svn server to github. I was very skeptical at first. Having to do separate commits and pushes seemed like a pain. The extra complexity seemed like a pain. It annoyed me that both git, Mercurial and Bazaar all do the same thing yet git it a bit harder. But actually it's really fantastic for these reasons... 1) Github provide a really high quality UI for browsing commits and code. 2) Github take away from the need to maintain you're own infrastructure, and it's free for OSS projects. 3) Git is insanely fast. 4) Git handles merging and branches much better. 5) Pull requests. And git is winning, so at the end of the day you have to pick the right horse. I totally understand the desire to stick with what you know, and to not have to reinvest by throwing out what you already have. Running a project that goes back 9 years myself, I know it's annoying to keep changing everything if it's "not broke" for what just seems like a fashion trend. However a whole generation of people are growing up around git and groups that don't adapt *look* like dinosaurs when viewed through the perspective of someone used to better tools. I'd also suggest not to get stuck in paranoid mode about wanting to control everything yourself. There are so many advantages to relying on github, and it's very reliable. Even if it did all go to crap, you could just switch to your own git server or whatever. I can't recommend changing enough. And full respect to you guys ISPConfig is awesome. I don't mean any rudeness at all, I wanted to share my own experience.
Well said Chris, I totally agree and would like to add a few more points. There are 2 possibilities, moving from SVN to Git is one issue that should have been done a year ago (IMHO) and the other one is whether to consider Github as the primary project host. I can't see any reason NOT to use Github if for no other simplistic reason that the auto markup and presentation of a README.md on every landing page. That makes informing first time end users from google searches a breeze. Gitorious does not provide this feature and finding project meta info is just a pain. Other superb project features are; . organisations... for free! . git based wiki at no extra overhead . a good enough issue tracker . the issue tracker gates the web interface to email AND back . issue tracker tags means it can also be used for discussions/features . clean interface with no ads . half the potential NEW ispconfig contributors probably already have github accounts Now if a move to Github is considered I would suggest 2 changes; one is to use the master branch as a stable rolling release target and develop in branches, and to split the repo so that what is currently /usr/local/ispconfig/interface/web can be independently updated from it's own repo. I have started hacking on a theme I will push to my own Github account, fine, but I have just bumped into an issue where I want to change the layout of the dashboard but dashboard/templates/dashboard.htm has some hardwired styles... now do I jump out of the self contained theme area and change a non-theme "internal core" template or do I try to submit a patch and argue for the change to dashboard/templates/dashboard.htm so I can modify my themes CSS file instead. Easiest is to hack the non-theme file directly and move on, but, obviously that change will be overwritten by a future update. Okay so next step is to see how do I lobby for a non-theme change and submit a patch? I don't know yet and that is what has led me to this thread by searching (this somewhat cruddy forum software) for an answer to how to contribute for a first time contributor. Frankly I still don't know how to lobby for this simple change nor how to contribute a patch and even if someone made my life so much easier by posting precise howto links I'm not sure I want to spend the time with antiquated forum/tracker software to be bothered. And here is the kicker for me. It would be easier for me to fork a snapshot of the stable 3.0.5.1 tarball and push it into my Github account and proceed without ever using an official future update. I would potentially waste less time making the changes I propose above and just managing my own ISPConfig-based project than "fighting" with project management system I otherwise have no interest in. This is totally FWIW and all praise to the current developers for such an excellent system but I do face a dilemma on how to proceed and will have to make a decision in the next few days as I suspect I will have to start hacking on more non-theme core files to get the layout changes I want. I also next need to start on a Dspam module and that will probably need even deeper changes and then later on I have to provide domain and certificate integration (if I am going to stick with ISPConfig for the long term) and I'm really not sure I want to battle with the current project management system on top of exploring the codebase in general.
have a look at my theme here: https://github.com/Foe-Services-Lab...ace/web/themes/ispc-larry/templates/dashboard These files overwrite the core files of ISPC I am with you on the topic as you can see in the first post.
Thanks Christian, would like to try it out so is there any chance the Installation instructions could have a brief sentence or 2 added. It's probably obvious but I'm flat out modifying my own theme. https://github.com/Foe-Services-Labs/ISPC-larry/blob/master/INSTALL.md
The current state of the master branch is a work in progress between 3.0.4.6 and 3.0.5.1 . Load the zip and copy all these folders: https://github.com/Foe-Services-Labs/ISPC-larry/tree/master/interface/web into the web folder of your ISPC installation. (testing only!) I am working on a full 3.0.5.1 compatible version.
Everyone is welcome to contribute to ispconfig as described many times here in the forum. If you wish to submit a patch, send it by email to dev [at] ispconfig [dot] org. If you wish to contribute regularily, then send a email to the above address to request a svn login. There are many tools available to work with svn repositores, you can browse them and integrate them directly into all major code editors. It's up to you guys if you want to help to improve the ispconfig project or work against it by splitting the development without contributing back. Why is it not so easy to contribute? As a general note why we are conservative regarding contributions: we tracked the time that it costs when a core devloper develops new a feature and that it costs to fix contributed code until it really works on all platforms, single and multiserve etc. (as most contributurs dont think about that) and does not breaky any existing features or extension. An example: We got a contribution of a new library that is used all over the system because the contributor thought that our old one was not "modern" enough, while the old one worked fine and was stable. At the first glance, the new lib worked fine so we included it, on the long term, more and more unpredictalbe behaviour occurred in various subsystems which at the end pointed to several design flaws in the new lib. Writing a modern version of our libray myself would have taken me about 2 hours, debugging all the issues in the contributed lib caused me and some other core devs about 15 - 20 hours of work till now. So basically this contribution costed the dev time that it would have taken to implement the top 2 or 3 most voted feature requests in the bugtracker. This is just one example but in fact the development of isponfig slowed down the more contributions we got as it binds the core devs to fixing issues only as the contributors left their code alone or when it gets "ugly" with debugging issues seriously in their code they were not available anymore. ISPConfig is not as simple as a cms system or similar software, ISPconfig is a ecosystem consisting of many server services were a minimal change in permissions of one file may bring a completely different subsystem down, so it requires a deep knowledge of Linux systems, programming and the way ispconfig works to contribute code to parts that are not themes or translations. So when we migtrate to a platform were we get many contributions from devs that we dont know their ispconfig specific knowledge, then it might destabilize the project and brings development to halt. @cfoe: It would be great if you would submit your theme to our official SVN as well when it is finished.
