[URGENT] Move away from Savannah/CVS
Hi folks, This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time. This also comes at a point in time when we've decided to pick a new version control system to replace CVS. I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution: http://code.google.com/hosting/ Here are the likely questions, and our answers: Q: why SVN and not git, arch, etc.? A: while a distributed repository makes good sense in theory, we fear that it will be a barrier to entry for new library software developers and we'll end up spending a disproportionate amount of time teaching and managing version control Q: why not host a SVN repo at koha.org or koha-fr.org? A: we're software developers, not proper sys admins, and at this point in our community development it's not fair to place the burden of managing the repo on any one development team. Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world. Q: what about licensing? A: Google is acting as a code repository, they are not assuming copyright on the code, or changing the license. We're sticking with GPL version 2 or greater. Any questions, see Google's Terms of Use: http://code.google.com/tos.html Q: What about losing all our version history? A: A move to Google will mean we'll lose our version history, that's true. Personally, I can't imagine we'd want to roll back any of the code in either rel_2_2, dev_week or head. I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua M. Ferraro wrote:
Hi folks,
This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time.
This also comes at a point in time when we've decided to pick a new version control system to replace CVS.
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution:
http://code.google.com/hosting/
Here are the likely questions, and our answers:
[snip]
Q: What about losing all our version history? A: A move to Google will mean we'll lose our version history, that's true. Personally, I can't imagine we'd want to roll back any of the code in either rel_2_2, dev_week or head.
I have not done anything other than a one-shot quick google search, but you should be able to preserve your history <http://blog.rot13.org/2006/09/how_to_import_subversion_into.html>
I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap.
Thanks for your efforts, gvb
Joshua M. Ferraro escribió:
I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap.
+1 Currently, SVN seems to be the best entry-point VCS, and I think we could benefit a lot from it. I also agree with hosting it in Google, they might be evil for libraries but not-so-much for developers :D Jose
Hi Koha team, "Joshua M. Ferraro" <jmf@liblime.com> writes:
Q: What about losing all our version history? A: A move to Google will mean we'll lose our version history, that's true.
Really? Migrating a CVS repository to a SVN repository is a "piece of cake" with cvs2svn. Once done, I would be very surprised if Google was not able to import an existing dump.
Personally, I can't imagine we'd want to roll back any of the code in either rel_2_2, dev_week or head.
Losing version history is not about being able to roll back but about being able to track modifications to know where a bug comes from, in my opinion. In any case, losing history is serious :-/ Concerning Google as SVN host, I think it is a good choice if you only consider the SVN repository. They indeed employ some Subversion developpers, such as Ben Collins-Sussman. They know Subversion as if they had made it ;-). In term of user interface and feature to manage a project, Google is far behind gna.org for example, but if Koha doesn't use the bugtracker or mailing-list... is that important? Cheers, -- Pierrick LE GALL
"Joshua M. Ferraro" <jmf@liblime.com> wrote:
This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time.
It's going to be back up today afternoon (EDT), according to reports found via www.gnu.org (did no-one think to look there?)
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution: http://code.google.com/hosting/
Why? From here, it looks like the best solutions are: 1. wait for Savannah to return, hopefully in a few hours as predicted; 2. host it ourselves from recent copies.
Here are the likely questions, and our answers:
Q: why SVN and not git, arch, etc.? A: while a distributed repository makes good sense in theory, we fear that it will be a barrier to entry for new library software developers and we'll end up spending a disproportionate amount of time teaching and managing version control
I think that is a weak reason. SVN is different to CVS anyway, so there's probably going to be time teaching and managing anyway. At least with git, the kernel hackers are famously intolerant of new confusing things, so it's been pretty well documented in various styles. There's also a cvs pserver emulation now, written by two NZ-based authors for the Open University UK, so the comments about losing developers seems bogus: nobody would have to migrate until they were ready! I'd be happy to host that on one of our machines in London, or elsewhere if you prefer. Despite the insulting comment:
[...] we're software developers, not proper sys admins [...]
I do currently work as a proper sysadmin (as much as a programmer, most weeks) which is why I've not been that active on koha lately. git is dead easy. Really. If you're going to do something dangerous, you almost always can take a backup and put it back if you break things (it's just a directory on disk in many ways). Give it a go. Also, if other koha developers had been using git and the cvs-compatibility commands, we could all have been working through this Savannah downtime.
Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world.
And backed by one of the least-loved corporations in the world today, boycotted by a wide range of groups, from privacy campaigners, through some private authors (after copyright problems), through to Students for a Free Tibet. I thought Google was even contraversial among librarians (despite offering some good ideas that we should adopt), but maybe I misunderstood. I think that moving to Google would mean that we're very likely to be in the same situation in a few months, when Google ceases the hosting service, decides to start charging larger profitable projects, or puts too many adverts on it. I believe neutral non-commercial public interest organisations like FSF will be more likely to sustain a loss-making hosting service than large commercial public corporations in the long term.
Q: what about licensing? A: Google is acting as a code repository, they are not assuming copyright on the code, or changing the license.
I hope that everyone has seen on the news that Google has just been accused of "rampant infringement of Plaintiffs’ copyrights" by Viacom. If they are trying to trample a huge publisher like Viacom, why should we think that the koha project's wishes would matter to them? Excuse my wariness on this, but I've seen good hosting services go strange in the past, changing project administrators and other tricks themselves. I've no idea whether Google would do that, but I also can't see what we could do to them if they did. Here are two other questions: How would we get commit access without giving our personal data to Google and/or opening a Googlemail account? What about (current or future) developers from countries where Google doesn't conduct business? [...]
I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap.
Sorry about the length of this email. Even now, it probably doesn't cover everything. I tried to discuss this with Joshua on IRC, but he refused. I feel a bit annoyed that proposals like this come from IRC without warning and then can't be discussed in real time there. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
"Joshua M. Ferraro" <jmf@liblime.com> wrote:
This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time. It's going to be back up today afternoon (EDT), according to reports found via www.gnu.org (did no-one think to look there?) Two days of downtime on a project repository and host for the
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution: http://code.google.com/hosting/
Why? From here, it looks like the best solutions are: 1. wait for Savannah to return, hopefully in a few hours as predicted; 2. host it ourselves from recent copies.
Here are the likely questions, and our answers:
Q: why SVN and not git, arch, etc.? A: while a distributed repository makes good sense in theory, we fear that it will be a barrier to entry for new library software developers and we'll end up spending a disproportionate amount of time teaching and managing version control
I think that is a weak reason. SVN is different to CVS anyway, so there's probably going to be time teaching and managing anyway. At least with git, the kernel hackers are famously intolerant of new confusing things, so it's been pretty well documented in various styles.
There's also a cvs pserver emulation now, written by two NZ-based authors for the Open University UK, so the comments about losing developers seems bogus: nobody would have to migrate until they were ready! I'd be happy to host that on one of our machines in London, or elsewhere if you prefer. Despite the insulting comment:
[...] we're software developers, not proper sys admins [...]
I do currently work as a proper sysadmin (as much as a programmer, most weeks) which is why I've not been that active on koha lately. The comment was certainly not meant as an insult to you or anyone else on koha-devel. It was specifically relevant to the current
Hi MJ, First, I'll say, as always, I appreciate your perspective, I think you do raise some good points. See responses below: ----- "MJ Ray" <mjr@phonecoop.coop> wrote: primary download for the project's releases is, in my view, an unacceptable service outage. The fact that they didn't even bother to put a splash page up for savannah.nongnu.org, giving a timeline for the outage, just aggravates the issue. This isn't the first time we've had major problems with Savannah, remember when the mailing lists were taking 4 days to deliver a mail? The point is not that savannah will be up in a day or two, but that we have no assurance that it won't just go down for days again... in this case, the timing was particularly bad as we'd planned to do some major work this week. project administrators, Chris, Paul and me.
git is dead easy. Really. If you're going to do something dangerous, you almost always can take a backup and put it back if you break things (it's just a directory on disk in many ways). Give it a go.
Also, if other koha developers had been using git and the cvs-compatibility commands, we could all have been working through this Savannah downtime. It's not that git, arch, etc., are hard to use ... it's the concept and management of a distributed version control system, and the lack of a clear leader in this arena that leads me to conclude that DVC is not quite there yet. We don't have much bandwidth to devote to managing a version control system in this community, I don't want to hop from DVC to DVC as I've seen so many other projects do. Again, this is my opinion, I'm not speaking for the Koha community or for Paul / Chris ... I'd love to hear everyone else's thoughts on the matter.
Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world.
And backed by one of the least-loved corporations in the world today, boycotted by a wide range of groups, from privacy campaigners, through some private authors (after copyright problems), through to Students for a Free Tibet. I thought Google was even contraversial among librarians (despite offering some good ideas that we should adopt), but maybe I misunderstood.
I think that moving to Google would mean that we're very likely to be in the same situation in a few months, when Google ceases the hosting service, decides to start charging larger profitable projects, or puts too many adverts on it. I believe neutral non-commercial public interest organisations like FSF will be more likely to sustain a loss-making hosting service than large commercial public corporations in the long term. I think this Savannah experience has alerted us to the need to make sure we aren't putting 'all our eggs in one basket' with regards to our project repository. I think establishing backup sites/ mirrors of the repository should be high on the priority list for sometime in the next few weeks (maybe ibiblio.org?). That said, Google has shown a good faith effort to support the OSS community, most notably with their Summer of Code project, and I've no reason to suspect they would abandon their hosting project. Personally, I don't subscribe to the 'Google is a corporation and therefore evil' theory; in fact, I'll go on the record as saying I think in many ways, Google's a great example of how corporations should be run. They provide a useful service to the world, they treat their employees right, and they sponsor initiatives to foster education and advocacy.
Q: what about licensing? A: Google is acting as a code repository, they are not assuming copyright on the code, or changing the license.
I hope that everyone has seen on the news that Google has just been accused of "rampant infringement of Plaintiffs’ copyrights" by Viacom. If they are trying to trample a huge publisher like Viacom, why should we think that the koha project's wishes would matter to them?
Excuse my wariness on this, but I've seen good hosting services go strange in the past, changing project administrators and other tricks themselves. I've no idea whether Google would do that, but I also can't see what we could do to them if they did. I can appreciate the wariness; whatever decision we make, it's clear we need to mirror the repository to ensure survival.
I'd like to hear more input from others, do MJ's concerns resonate? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua M. Ferraro wrote:
Hi MJ,
First, I'll say, as always, I appreciate your perspective, I think you do raise some good points. See responses below:
----- "MJ Ray" <mjr@phonecoop.coop> wrote:
[snip]
[...] we're software developers, not proper sys admins [...] I do currently work as a proper sysadmin (as much as a programmer, most weeks) which is why I've not been that active on koha lately. The comment was certainly not meant as an insult to you or anyone else on koha-devel. It was specifically relevant to the current project administrators, Chris, Paul and me.
git is dead easy. Really. If you're going to do something dangerous, you almost always can take a backup and put it back if you break things (it's just a directory on disk in many ways). Give it a go.
Also, if other koha developers had been using git and the cvs-compatibility commands, we could all have been working through this Savannah downtime.
It's not that git, arch, etc., are hard to use ... it's the concept and management of a distributed version control system, and the lack of a clear leader in this arena that leads me to conclude that DVC is not quite there yet. We don't have much bandwidth to devote to managing a version control system in this community, I don't want to hop from DVC to DVC as I've seen so many other projects do. Again, this is my opinion, I'm not speaking for the Koha community or for Paul / Chris ... I'd love to hear everyone else's thoughts on the matter.
There is a clear leader and it is "git." Linus looked at all of the DVCs and found them wanting, so he wrote git. Since then it has been enhanced tremendously and is being used by a huge number of people developing linux as well as those that are compiling their own kernels but not actively developing linux. There are other projects using git as well: I'm aware of x.org and u-boot and I know there are more.
Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world. And backed by one of the least-loved corporations in the world today, boycotted by a wide range of groups, from privacy campaigners, through some private authors (after copyright problems), through to Students for a Free Tibet. I thought Google was even contraversial among librarians (despite offering some good ideas that we should adopt), but maybe I misunderstood.
Well, perhaps a distant third after Microsoft and Walmart. :-) IMHO, most of the people boycotting Google are doing it more to grind their own axe than because there is a substantial problem with Google. You get a lot more press by announcing you are boycotting Google than by announcing you are boycotting iServ. [snip]
Excuse my wariness on this, but I've seen good hosting services go strange in the past, changing project administrators and other tricks themselves. I've no idea whether Google would do that, but I also can't see what we could do to them if they did. I can appreciate the wariness; whatever decision we make, it's clear we need to mirror the repository to ensure survival.
I'd like to hear more input from others, do MJ's concerns resonate?
No major resonance here. Best regards, gvb
I don't think that the reputation of Google among the larger library community should have much of an impact on the hosting decision. Google does a lot of great things, and a lot of not so great things. I think that the things it does around hosting open source projects should be the major contributing factor in the decision. I also agree that the decision on hosting shouldn't be taken lightly and perhaps shouldn't be undertaken with the intention of making that decision in a single day. The much more pressing matter (in my opinion) is that the code is currently not available for download by end-users (I myself am looking to download it). While the decision for long-term hosting is being made, at least, a copy of the most recent stable release should be made available immediately and linked to via koha.org. The only thing that having no end product to download is doing is losing the project end users.
Hi Paul, ----- "Paul_Shannon" <Paul_shannon@carleton.ca> wrote:
The much more pressing matter (in my opinion) is that the code is currently not available for download by end-users (I myself am looking to download it). While the decision for long-term hosting is being made, at least, a copy of the most recent stable release should be made available immediately and linked to via koha.org.
The only thing that having no end product to download is doing is losing the project end users. I've triggered an update to koha.org and the links will be updated very soon. In the meantime, here's the link to the latest version:
http://contribs.koha.org/koha-2.2.8.tar.gz Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Just FYI everyone, I've managed to get in touch with one of the Savannah administrators. The Savannah server (!! there's only one?) experienced 'a complex hardware failure'. This turns out to have been a unrecoverable disk failure. The last successful backup was 8:30pm EDT on Sunday March 11th. They are still waiting for parts to be shipped so they can do a recovery. -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Wed, Mar 14, 2007 at 11:56:46AM -0500, Joshua M. Ferraro wrote:
----- "MJ Ray" <mjr@phonecoop.coop> wrote:
git is dead easy. Really. If you're going to do something dangerous, you almost always can take a backup and put it back if you break things (it's just a directory on disk in many ways). Give it a go.
Also, if other koha developers had been using git and the cvs-compatibility commands, we could all have been working through this Savannah downtime.
It's not that git, arch, etc., are hard to use ... it's the concept and management of a distributed version control system, and the lack of a clear leader in this arena that leads me to conclude that DVC is not quite there yet. We don't have much bandwidth to devote to managing a version control system in this community, I don't want to hop from DVC to DVC as I've seen so many other projects do. Again, this is my opinion, I'm not speaking for the Koha community or for Paul / Chris ... I'd love to hear everyone else's thoughts on the matter.
I remember seeing that about git as well, that there are cvs-compatibility commands. I would much prefer to go with a distributed system than centralized. I have not used git, but have friends who have, and it has really helped their projects a lot. If someone knows how to set up a git repository, now is a great time to do it. Then at least people can play with git while we cannot access CVS. -kolibrie
"Joshua M. Ferraro" <jmf@liblime.com> wrote:
Two days of downtime on a project repository and host for the primary download for the project's releases is, in my view, an unacceptable service outage. The fact that they didn't even bother to put a splash page up for savannah.nongnu.org, giving a timeline for the outage, just aggravates the issue.
It seems that the maintainers expected people to look for news on www.gnu.org or www.fsf.org, all the available on-site sysadmin support is working on recovering the filesystem (so wire-swapping to bring up a splash screen wasn't an immediate option) and changing DNS would make it slower to bring back the service once it returns. If anyone wants to give more resources to Savannah, FSF accepts donations by transfer https://www.fsf.org/donate/bankdetails/ - specify that the money is for Savannah.
This isn't the first time we've had major problems with Savannah, remember when the mailing lists were taking 4 days to deliver a mail?
Not really. Delays to email are irritating but nowhere near as frustrating as the old commit delays on the last corporation-hosted central repository (Sourceforge).
The point is not that savannah will be up in a day or two, but that we have no assurance that it won't just go down for days again... in this case, the timing was particularly bad as we'd planned to do some major work this week.
We have no assurance that any hosting service will stay up at a particularly vital moment. Self-reliance is needed. Distributed version control should help that. [...]
Also, if other koha developers had been using git and the cvs-compatibility commands, we could all have been working through this Savannah downtime. It's not that git, arch, etc., are hard to use ... it's the concept and management of a distributed version control system,
What do people find so hard about this concept? Instead of sending all traffic over the network to a central store, you send it to a store on your local disk. Then, when you're ready, you can synchronise any two stores by committing to or merging from it. To use an analogue, CVS is like connected IMAP, while git is like disconnected IMAP. I don't read many complaints about how disconnected IMAP is a difficult concept (although disappointingly few ISPs and mail clients support it still).
and the lack of a clear leader in this arena that leads me to conclude that DVC is not quite there yet. We don't have much bandwidth to devote to managing a version control system in this community, I don't want to hop from DVC to DVC as I've seen so many other projects do.
So don't do it. Pick one and stick with it, come what may. Each of the current DVCs has at least one flaw which may rule it out, but then so does SVN. They mostly work with similar ideas, with the possible exception of Aegis IIRC.
[...] I think establishing backup sites/ mirrors of the repository should be high on the priority list for sometime in the next few weeks (maybe ibiblio.org?).
Great. This seems a good idea. Mirroring is something which is designed into any distributed version control system from the outset. Even if you choose not to use it at first, it's usually not too difficult. Can you tell me more about ibiblio.org's repository mirroring? I know they mirror tarballs and big FTP sites in this field, but I'd not heard about their repository mirroring.
That said, Google has shown a good faith effort to support the OSS community, most notably with their Summer of Code project, and I've no reason to suspect they would abandon their hosting project.
They do lots of other marketing too. That's what Code is to them: marketing. Marketing themselves to the tech-savvy opinion formers, to prospective developers, and so on. When it ceases to be justifiable as marketing, their Code offerings will either change (adverts, finding ways to monetise the code search, or otherwise) or close.
Personally, I don't subscribe to the 'Google is a corporation and therefore evil' theory; [...]
Me neither. Misdescribing the counter-argument like that is a very dishonourable tactic. It's also stupid to suggest that about me. Given that I'm a member of one of the UK's largest retail corporation groups, I hope it's obvious that I don't think all corporations are evil.
in fact, I'll go on the record as saying I think in many ways, Google's a great example of how corporations should be run. [...]
I'd agree that it's seems efficiently-run, but I disagree that it's a great example. It is slow to fix bugs (even serious ones sometimes), amoral (see the China debate), and externalises costs (also known as polluting) at a frightening rate (such as invite-spamming). Google has taken services off-line temporarily and changed terms (including ad services, where some people pay big money for the services) without warning in the past and will presumably do so again. I don't think their size gives us certainty. If anything, it makes it harder for us to influence them. In short, I think we shouldn't trust Google with Koha when there are so many alternatives. My first preference is to trust ourselves (preferably with wider use of DVC). My second would be to trust another non-profit foundation. As an aside to that, I would really like to have CVS-compatibility as far as possible, if there's a central service. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
Joshua M. Ferraro a écrit :
Hi folks,
This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time.
mmm... thinking a little bit more, I think it's not that urgent, but that's something we have to do anyway. So let's work on it now ;-)
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution: http://code.google.com/hosting/
my 2 main concerns here are : - use a widely known VCS. We need MORE developpers, not LESS. And I strongly think it's the main concern we must achieve here. - use a quick / efficient / ... solution. At least more than CVS ;-) Once we will have choosen the solution, let's go with the hosting platform & tools wee need. SVN sounds a good candidate to me. Distributed solutions sounds less heavily spread, and I really don't nothing with them. I've read arch doc a while ago, and I was not really enthousiasmed by my reading (but had no experience, so it's just a feeling) Another + point with SVN is that it's "cvs child", so it's quite easy to move from one to the other. Hosting tools / platform. savannah is not only a repository, but also a ML system, bug tracking, release & news system... - Release system is really poor (far more poor than sourceforge : we can't have a clear separation of the different versions : just a "ftp website". That's probably why jmf & LibLime got so many feedbacks with 2.3.0 UNSTABLE version, but that's not written clearly on the website) - we use bugs.koha.org for bug tracking - we have www.koha.org & www.koha-fr.org for most news. So, who can host a SVN repository and, but that's less important, other tools ? i'm a little bit afraid by google here : librarian world really looks ggl as "evil" (I agree with slef opinion here), and I don't want to be counter-productive by moving to ggl too quickly (some ppl of proprietary software could rise the fact & use it against our commercials offers -even if I agree it would be stupid, we can't ignore that...-) Thus, I think the SVN choice is the good one, but I would prefer another hosting system. Savannah works quite correctly, we can afford a 2 days failure rarely. We moved from SF for 2 reasons : ML very very very slow & SF position not being so clear for the future. If savannah offered SVN, I would say "move to SVN, but keep savannah". gna.org offers a quite correct hosting platform, works fine (it hosts OpenCataloger, that will reach v1.0 quite soon now, and Dolibarr, a software I use for my invoice. Never had problems with it). I'm open to another proposal, but not enthusiasm by google. Last note : I don't think that's the kind of decision we should take in 1 day. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
Paul POULAIN <paul.poulain@free.fr> writes:
gna.org offers a quite correct hosting platform, works fine (it hosts OpenCataloger, that will reach v1.0 quite soon now, and Dolibarr, a software I use for my invoice. Never had problems with it).
PhpWebGallery moved to gna.org 3 years ago and I migrated from CVS to SVN 1.5 year ago. If I remember well, only one outage day. SVN is impressively fast (gna.org and I use the same famous french provider, Free.fr). I highly recommend Gna! to Koha development team :-) For non French developpers, check the speed by checkouting those 2 projects: svn co http://svn.gna.org/svn/phpwebgallery/trunk phpwebgallery svn co http://svn.gna.org/svn/opencataloger/trunk opencataloger Other argument: mailing-list are also very fast. SVN commits are always notified in less than 5 minutes. -- Pierrick LE GALL
Le mercredi 14 mars 2007 à 18:47 +0100, Pierrick LE GALL a écrit :
Paul POULAIN <paul.poulain@free.fr> writes:
gna.org offers a quite correct hosting platform, works fine (it hosts OpenCataloger, that will reach v1.0 quite soon now, and Dolibarr, a software I use for my invoice. Never had problems with it).
PhpWebGallery moved to gna.org 3 years ago and I migrated from CVS to SVN 1.5 year ago. If I remember well, only one outage day. SVN is impressively fast (gna.org and I use the same famous french provider, Free.fr). I highly recommend Gna! to Koha development team :-)
For non French developpers, check the speed by checkouting those 2 projects:
svn co http://svn.gna.org/svn/phpwebgallery/trunk phpwebgallery svn co http://svn.gna.org/svn/opencataloger/trunk opencataloger
Other argument: mailing-list are also very fast. SVN commits are always notified in less than 5 minutes.
Hi all, I confirm that gna is really great. SVN commit are fast notified by the mailing list *but* keep in mind there is no diff into these mails, just a link to read it on the web !! It is an important missed feature I think... cheers, -- Antoine Farnault
Hello all, The CCFLS folks are fine with svn (especially Kyle), and neutral about google. I personally will miss savannah's fancy source browsing capabilities. It's good for tracing bugs. We're willing to host a mirror, also. Just let us know what you need. Cindy -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Network Administrator Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org
Cindy Murdock wrote:
Hello all,
The CCFLS folks are fine with svn (especially Kyle), and neutral about google. I personally will miss savannah's fancy source browsing capabilities. It's good for tracing bugs.
We're willing to host a mirror, also. Just let us know what you need.
Cindy
gitweb does a competent source browse. <http://git.kernel.org/> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree> Browsing net/compat.c: <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/compat.c;h=1f32866d09b7f3ba6deae83fdffd7044fb8e3b6a;hb=HEAD> Example commit differences: <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=effee6a00034a8d83a6dea6d221820d87364ac21> Best regards, gvb
On 14/03/07, Joshua M. Ferraro <jmf@liblime.com> wrote:
Hi folks,
This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time.
This also comes at a point in time when we've decided to pick a new version control system to replace CVS.
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution:
http://code.google.com/hosting/
Here are the likely questions, and our answers:
Q: why SVN and not git, arch, etc.? A: while a distributed repository makes good sense in theory, we fear that it will be a barrier to entry for new library software developers and we'll end up spending a disproportionate amount of time teaching and managing version control
Q: why not host a SVN repo at koha.org or koha-fr.org? A: we're software developers, not proper sys admins, and at this point in our community development it's not fair to place the burden of managing the repo on any one development team.
Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world.
Q: what about licensing? A: Google is acting as a code repository, they are not assuming copyright on the code, or changing the license. We're sticking with GPL version 2 or greater.
Any questions, see Google's Terms of Use:
http://code.google.com/tos.html
Q: What about losing all our version history? A: A move to Google will mean we'll lose our version history, that's true. Personally, I can't imagine we'd want to roll back any of the code in either rel_2_2, dev_week or head.
I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap.
Just don't forget that code.google.com only offers 100MB of SVN hosting per project. Probably not an issue with Koha, but I thought it would be worth mentioning. Dan Scott
I just wanted to throw my 2 cents in. First, on the move from CVS to Subversion. I know there have been fears circulating about learning a new vcs, but I've used both CVS and SVN, and I have to say I find subversion much easier to use in my opinion. It was written by the same author as CVS to replace CVS and to address many issues CVS had. I use subversion for my koha-tools repository on Sourceforge. Put simply, I fully endorse a move from CVS to Subversion. As for switching to Google Code. I do not believe that Google is evil. I believe they have reliable hardware, and I also believe that they fully endorse open source and are trying to benefit the FOSS community while benefiting themselves. I think we should be backing up our VCS whatever it may be on a weekly or nightly basis. That way, I whoever is hosting the repository were to dissapear overnight, we wouldn't lose our code history. Kyle On 3/15/07, Dan Scott <denials@gmail.com> wrote:
On 14/03/07, Joshua M. Ferraro <jmf@liblime.com> wrote:
Hi folks This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time.
This also comes at a point in time when we've decided to pick a new version control system to replace CVS.
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution:
http://code.google.com/hosting/
Here are the likely questions, and our answers:
Q: why SVN and not git, arch, etc.? A: while a distributed repository makes good sense in theory, we fear that it will be a barrier to entry for new library software developers and we'll end up spending a disproportionate amount of time teaching and managing version control
Q: why not host a SVN repo at koha.org or koha-fr.org? A: we're software developers, not proper sys admins, and at this point in our community development it's not fair to place the burden of managing the repo on any one development team.
Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world.
Q: what about licensing? A: Google is acting as a code repository, they are not assuming copyright on the code, or changing the license. We're sticking with GPL version 2 or greater.
Any questions, see Google's Terms of Use:
http://code.google.com/tos.html
Q: What about losing all our version history? A: A move to Google will mean we'll lose our version history, that's true. Personally, I can't imagine we'd want to roll back any of the code in either rel_2_2, dev_week or head.
I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap.
Just don't forget that code.google.com only offers 100MB of SVN hosting per project. Probably not an issue with Koha, but I thought it would be worth mentioning.
Dan Scott
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System
"Kyle Hall" <kyle.m.hall@gmail.com> wrote:
[...] It was written by the same author as CVS to replace CVS and to address many issues CVS had. [...]
Sorry to doubt, but how do you figure that? I see the CVS Authors list: http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/AUTHORS?view=auto and the SVN committers list: http://svn.collab.net/repos/svn/trunk/COMMITTERS and didn't find any overlap among the core. By coincidence, Google's profiting from personal data and the privacy implications was a featured item on yesterday's Newsnight on BBC TV. See also: http://news.bbc.co.uk/1/hi/programmes/newsnight/6456023.stm http://news.bbc.co.uk/1/hi/technology/6453137.stm Personally, I'm a bit concerned that moving koha.org to the US puts too many of our eggs under one government's foot (excuse the mixed metaphor), even without requiring developers to deal with the more malleable Google instead of FSF. Hope that explains, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
It's not like we're using export controlled cryptography, the reason OpenBSD is not hosted in the US. Kyle On 3/16/07, Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
Personally, I'm a bit concerned that moving koha.org to the US puts too many of our eggs under one government's foot
I'm not particularly fond of my current government's foot, but I'm curious what you're thinking could be the consequences of having koha.org in the US?
-- Owen
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System
I can't remember where I read it, but I just pulled this from the wikipedia page: *Subversion* is an open source <http://en.wikipedia.org/wiki/Open_source>application for revision control <http://en.wikipedia.org/wiki/Revision_control>. Also commonly referred to as *svn* or *SVN*, Subversion is designed specifically to be a modern replacement for CVS<http://en.wikipedia.org/wiki/Concurrent_Versions_System>and shares a number of the same key developers. I may be wrong, as could the wikipedia page. But I've read it in multiple places. Sorry I can't cite my sources better ; ) Kyle On 3/16/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Kyle Hall" <kyle.m.hall@gmail.com> wrote:
[...] It was written by the same author as CVS to replace CVS and to address many issues CVS had. [...]
Sorry to doubt, but how do you figure that?
I see the CVS Authors list: http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/AUTHORS?view=auto and the SVN committers list: http://svn.collab.net/repos/svn/trunk/COMMITTERS and didn't find any overlap among the core.
By coincidence, Google's profiting from personal data and the privacy implications was a featured item on yesterday's Newsnight on BBC TV. See also: http://news.bbc.co.uk/1/hi/programmes/newsnight/6456023.stm http://news.bbc.co.uk/1/hi/technology/6453137.stm
Personally, I'm a bit concerned that moving koha.org to the US puts too many of our eggs under one government's foot (excuse the mixed metaphor), even without requiring developers to deal with the more malleable Google instead of FSF.
Hope that explains, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
-- IT Tech Crawford County Federated Library System
"Kyle Hall" <kyle.m.hall@gmail.com> wrote:
I may be wrong, as could the wikipedia page. But I've read it in multiple places. Sorry I can't cite my sources better ; ) [...]
OK, I've asked wikipedia authors for their sources at the URL http://en.wikipedia.org/wiki/Talk:Subversion_%28software%29#No_source_given:... You may find that the other multiple places you read also believed wikipedia unchecked. Be very careful about believing anything written on reader-editable sites: it's usually correct, but not always. I think there's some famous examples of people coming a cropper this way. These people do it well: http://www.theyesmen.org/ Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
Do you trust O'Reilly <http://www.oreillynet.com/pub/au/1438>? On another note, who cares? This is not germane to the topic at hand. It was just a passing comment. I think you need to relax a little ; ) Kyle
You may find that the other multiple places you read also believed wikipedia unchecked. Be very careful about believing anything written on reader-editable sites: it's usually correct, but not always. I think there's some famous examples of people coming a cropper this way. These people do it well: http://www.theyesmen.org/
Regards, -- MJ Ray
-- IT Tech Crawford County Federated Library System
"Kyle Hall" <kyle.m.hall@gmail.com> wrote:
Do you trust O'Reilly <http://www.oreillynet.com/pub/au/1438>?
Enough for this. Thanks for the link. So, one of subversion's managers was the author of anon-cvs, if I understand that right.
On another note, who cares? This is not germane to the topic at hand. It was just a passing comment.
If it's off-topic, don't mention it. OTOH, I think it was relevant, suggesting that subversion was made by experienced gurus. Maybe, but no more than many: svn devels didn't seem to understand Tom Lord's explanations (he's good on version control design, but maybe not so good on user interaction), I've seen horribly-wedged svn servers and IIRC svn's early mv command was basically an rm and an add, which was no better than cvs.
I think you need to relax a little ; )
Don't rely on detecting emotional states from the words people use - it varies massively from place to place. Instead, rely on what they write. In other words: I'm quite relaxed. Thanks for your concern. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
No problem, MJ. For the rest of the developers, maybe we should schedule an irc meeting about this issue. It seems to be quite a hot topic ; ) Kyle On 3/16/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Kyle Hall" <kyle.m.hall@gmail.com> wrote:
Do you trust O'Reilly <http://www.oreillynet.com/pub/au/1438>?
Enough for this. Thanks for the link. So, one of subversion's managers was the author of anon-cvs, if I understand that right.
On another note, who cares? This is not germane to the topic at hand. It was just a passing comment.
If it's off-topic, don't mention it. OTOH, I think it was relevant, suggesting that subversion was made by experienced gurus. Maybe, but no more than many: svn devels didn't seem to understand Tom Lord's explanations (he's good on version control design, but maybe not so good on user interaction), I've seen horribly-wedged svn servers and IIRC svn's early mv command was basically an rm and an add, which was no better than cvs.
I think you need to relax a little ; )
Don't rely on detecting emotional states from the words people use - it varies massively from place to place. Instead, rely on what they write. In other words: I'm quite relaxed. Thanks for your concern.
Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
-- IT Tech Crawford County Federated Library System
thinking of it, I was wondering wether a distributed VCS should be considered as a "Release Manager" oriented VCS. I explain : unless i'm mistaken, it means : - kados is the RM - paul & chris are working on some feature - paul "commit" the feature to kados repository, who will accept it (or how is he warned that I made something ?) - chris update his copy from kados one. iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we have a RM that can afford that task/responsability ? Once again, I may be mistaken, but i'm a little bit less enthusiasm if i'm right... -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
Paul POULAIN <paul.poulain@free.fr> wrote:
I explain : unless i'm mistaken, it means : - kados is the RM - paul & chris are working on some feature - paul "commit" the feature to kados repository, who will accept it (or how is he warned that I made something ?) - chris update his copy from kados one.
Not necessarily. If kados permits it (this is a RM policy decision, I think), then you can accept your own commit into his release branch. As to how he's warned, that's the same sort of question as now: how is he warned about your CVS commits? CVS status screens, commit mails...
iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we have a RM that can afford that task/responsability ?
Paul probably knows more than most current developers: how much would it cost? From IRC, I think people see a more active review as a good idea, but we don't know whether we have enough resources. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
Paul POULAIN wrote:
thinking of it, I was wondering wether a distributed VCS should be considered as a "Release Manager" oriented VCS.
I explain : unless i'm mistaken, it means : - kados is the RM - paul & chris are working on some feature - paul "commit" the feature to kados repository, who will accept it (or how is he warned that I made something ?) - chris update his copy from kados one.
iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we have a RM that can afford that task/responsability ? Once again, I may be mistaken, but i'm a little bit less enthusiasm if i'm right...
This is where a D-VCS *really* shines (at least git, probably the others as well). The advantages of D-VCS is that you have not only branches but also replicated repositories to work with. The following is how things work with linux and git. It may apply to other D-VCS, but I don't know. You have a development master repository. For linux, it is Linus Torvald's on kernel.org. For Koha, this likely would be the 3.x development one. Only Paul Poulain (or whoever is the development master) does commits into this repo. Paul and Chris would have their own feeder repos and _ask_ Paul to pull changes, they would not (normally) push changes into the RM repo. The RM (Kados) also has a master repository. Bugfixes and also any backporting of new features get pulled into the repository by Kados. Pulls is the norm, pushes are generally not done. You then have feeder repositories that the master maintainer (Paul for the development repo, Kados for the release repo) pulls improvements from after they've been vetted. This would be Paul & Chris & everybody else in a hierarchy. All the koha developers then have their local working repository, which is a clone of the master + "value added". In the local repository, they pull changes from the master RM repo to keep up to date, as well as doing their local work. If another feeder repo has a change they want/need, they can pull that change directly from the feeder repo (including "cherry-picking" changes). Since git keeps track of changes by their hash name, when the master RM repo picks up a feeder's change, the local repos that already have that change just say "been there, done that, fast forward" and life is good. Otherwise a merge is done and life is still good (except for a collision, but that is unavoidable and is no different than what happens with CVS/SVN). Local changes are source controlled in the local repo - something I've never succeeded in doing well with CVS/SVN, but is transparently trivial with git. When a local change is considered ready for inclusion, by convention a branch is created in the local repo with a distinctive name and the appropriate upstream repo owner is notified (traditionally by posting a patch on the developers' email list so everybody can review the change). The upstream repo owner then pulls the change into the upstream repo, ultimately ending up in the master RM repo (or the "new HEAD" repo) and spreading back out over the world from there. Poor ASCII-art diagram: backport Development --------> Release ^ ^ ^ ^ | \ _______/ / | \ / _____/ bugfixes feeder1 feeder2 / ^ ^ ^ ^ ^ / / |/ | \ / dev1 | dev3 dev4 dev2 (I tried to make a line from "dev2" into both feeder1 and feeder2 - the tree need not be a strict hierarchy. Dev2 can generate a change that gets pulled into both feeder1 and feeder2 and subsequently into Development with no confusion - if feeder2 gets pulled into Development first, the duplicate in feeder1 will be identified and "fast forwarded.") HTH, gvb
I've been chatting with kados, and he suggested I get some feedback from Jerry. It seems that if we switched to git we would need someone full-time just managing commits from the way I read Jerry Van Baren's post. It seems like the koha community, though dedicated, just isn't big enough to absorb the cost of losing development time to managing source code control. I doubt there are many programmers out there that would prefer to be managing the code they've written rather than writing more code ; ) What leads me to these conclusions is the whole hierarchy of 'pull' rather than push. It means that at each level of development, say me->chris->josh, everyone except the first person (me ) has to actively pull changes from the level below them. Please correct me if I am mistaken. Kyle On 3/16/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
Paul POULAIN wrote:
thinking of it, I was wondering wether a distributed VCS should be considered as a "Release Manager" oriented VCS.
I explain : unless i'm mistaken, it means : - kados is the RM - paul & chris are working on some feature - paul "commit" the feature to kados repository, who will accept it (or how is he warned that I made something ?) - chris update his copy from kados one.
iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we have a RM that can afford that task/responsability ? Once again, I may be mistaken, but i'm a little bit less enthusiasm if i'm right...
This is where a D-VCS *really* shines (at least git, probably the others as well). The advantages of D-VCS is that you have not only branches but also replicated repositories to work with. The following is how things work with linux and git. It may apply to other D-VCS, but I don't know.
You have a development master repository. For linux, it is Linus Torvald's on kernel.org. For Koha, this likely would be the 3.x development one. Only Paul Poulain (or whoever is the development master) does commits into this repo. Paul and Chris would have their own feeder repos and _ask_ Paul to pull changes, they would not (normally) push changes into the RM repo.
The RM (Kados) also has a master repository. Bugfixes and also any backporting of new features get pulled into the repository by Kados. Pulls is the norm, pushes are generally not done.
You then have feeder repositories that the master maintainer (Paul for the development repo, Kados for the release repo) pulls improvements from after they've been vetted. This would be Paul & Chris & everybody else in a hierarchy.
All the koha developers then have their local working repository, which is a clone of the master + "value added". In the local repository, they pull changes from the master RM repo to keep up to date, as well as doing their local work. If another feeder repo has a change they want/need, they can pull that change directly from the feeder repo (including "cherry-picking" changes). Since git keeps track of changes by their hash name, when the master RM repo picks up a feeder's change, the local repos that already have that change just say "been there, done that, fast forward" and life is good. Otherwise a merge is done and life is still good (except for a collision, but that is unavoidable and is no different than what happens with CVS/SVN).
Local changes are source controlled in the local repo - something I've never succeeded in doing well with CVS/SVN, but is transparently trivial with git. When a local change is considered ready for inclusion, by convention a branch is created in the local repo with a distinctive name and the appropriate upstream repo owner is notified (traditionally by posting a patch on the developers' email list so everybody can review the change). The upstream repo owner then pulls the change into the upstream repo, ultimately ending up in the master RM repo (or the "new HEAD" repo) and spreading back out over the world from there.
Poor ASCII-art diagram:
backport Development --------> Release ^ ^ ^ ^ | \ _______/ / | \ / _____/ bugfixes feeder1 feeder2 / ^ ^ ^ ^ ^ / / |/ | \ / dev1 | dev3 dev4 dev2
(I tried to make a line from "dev2" into both feeder1 and feeder2 - the tree need not be a strict hierarchy. Dev2 can generate a change that gets pulled into both feeder1 and feeder2 and subsequently into Development with no confusion - if feeder2 gets pulled into Development first, the duplicate in feeder1 will be identified and "fast forwarded.")
HTH, gvb
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System
Yes on the concepts, no on the level of effort. :-) I'm not very familiar with koha's current VCS structure and methods since I'm not actively developing koha code (I installed koha at the private school that I donate my time too ;-) and only monitor the list for developments). It sounds like there are several developers with write access to the master repo. This could be carried forward, but isn't the way git is being used elsewhere. Git is being used mostly as single-user per repo with the repos being available via http: or git: (preferably the latter). Hierarchy with single developers is an excellent way of providing scaling and preventing inadvertent interference. Git background and tutorials: <http://git.or.cz/> <http://www.kernel.org/pub/software/scm/git/docs/tutorial.html> <http://www.kernel.org/pub/software/scm/git/docs/everyday.html> The following is the concept, likely not 100% correct since I didn't actually execute the commands. It is also just one way of doing it (for example, pull is a fetch+merge - doing a fetch, inspect the potential changes, and then merge them has its benefits). Kyle@kyle.com would have his repo and create New Code[tm]. He would either do this development in a new branch in his repo or would create a new branch for Chris: git checkout -b for_chris git pull . <commitID> (where <commitID> is his previously committed changes in his master branch) and email Chris "hey, pull for_chris". Chris@chris.com would pull it into his repo by creating a temporary testing branch "from_kyle" and pulling the changes: git checkout -b from_kyle git pull git://kyle.com for_chris Chris tests the updates and likes them. He merges it into his mainline: git checkout master git pull . from_kyle and emails Josh "hey, pull "from_kyle". Josh@koha.org does the equivalent, but, since he trusts Chris, doesn't bother creating a temporary branch for testing: git pull git://chris.com from_kyle Some time later Chris and Kyle update their copies from koha.org: git pull at which time the changes that came from Chris will be fast forwarded and they can delete their respective branches Kyle: git branch -d for_chris Chris: git branch -d from_kyle It really doesn't take much time because, by the time the changes bubble to the top, the trust and testing has been performed and the change just needs to be pulled. Since the pulls are just the changes, they are very quick. Linus is doing this at the top level for linux with a handful of lieutenants (I don't know the current count, probably under 10). The number of active developers and changed lines of code is or should be way higher than what koha has. Linus isn't doing it full time, he still has time to rewrite portions of gnome. <http://www.linux.com/article.pl?sid=07/02/16/1937237> ;-) The git methodology scales well because it was designed from the ground up to be robust, efficient, and scalable. gvb Kyle Hall wrote:
I've been chatting with kados, and he suggested I get some feedback from Jerry.
It seems that if we switched to git we would need someone full-time just managing commits from the way I read Jerry Van Baren's post. It seems like the koha community, though dedicated, just isn't big enough to absorb the cost of losing development time to managing source code control. I doubt there are many programmers out there that would prefer to be managing the code they've written rather than writing more code ; )
What leads me to these conclusions is the whole hierarchy of 'pull' rather than push. It means that at each level of development, say me->chris->josh, everyone except the first person (me ) has to actively pull changes from the level below them. Please correct me if I am mistaken.
Kyle
On 3/16/07, *Jerry Van Baren* <gerald.vanbaren@smiths-aerospace.com <mailto:gerald.vanbaren@smiths-aerospace.com>> wrote:
Paul POULAIN wrote: > thinking of it, I was wondering wether a distributed VCS should be > considered as a "Release Manager" oriented VCS. > > I explain : unless i'm mistaken, it means : > - kados is the RM > - paul & chris are working on some feature > - paul "commit" the feature to kados repository, who will accept it (or > how is he warned that I made something ?) > - chris update his copy from kados one. > > iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we > have a RM that can afford that task/responsability ? > Once again, I may be mistaken, but i'm a little bit less enthusiasm if > i'm right...
This is where a D-VCS *really* shines (at least git, probably the others as well). The advantages of D-VCS is that you have not only branches but also replicated repositories to work with. The following is how things work with linux and git. It may apply to other D-VCS, but I don't know.
You have a development master repository. For linux, it is Linus Torvald's on kernel.org <http://kernel.org>. For Koha, this likely would be the 3.x development one. Only Paul Poulain (or whoever is the development master) does commits into this repo. Paul and Chris would have their own feeder repos and _ask_ Paul to pull changes, they would not (normally) push changes into the RM repo.
The RM (Kados) also has a master repository. Bugfixes and also any backporting of new features get pulled into the repository by Kados. Pulls is the norm, pushes are generally not done.
You then have feeder repositories that the master maintainer (Paul for the development repo, Kados for the release repo) pulls improvements from after they've been vetted. This would be Paul & Chris & everybody else in a hierarchy.
All the koha developers then have their local working repository, which is a clone of the master + "value added". In the local repository, they pull changes from the master RM repo to keep up to date, as well as doing their local work. If another feeder repo has a change they want/need, they can pull that change directly from the feeder repo (including "cherry-picking" changes). Since git keeps track of changes by their hash name, when the master RM repo picks up a feeder's change, the local repos that already have that change just say "been there, done that, fast forward" and life is good. Otherwise a merge is done and life is still good (except for a collision, but that is unavoidable and is no different than what happens with CVS/SVN).
Local changes are source controlled in the local repo - something I've never succeeded in doing well with CVS/SVN, but is transparently trivial with git. When a local change is considered ready for inclusion, by convention a branch is created in the local repo with a distinctive name and the appropriate upstream repo owner is notified (traditionally by posting a patch on the developers' email list so everybody can review the change). The upstream repo owner then pulls the change into the upstream repo, ultimately ending up in the master RM repo (or the "new HEAD" repo) and spreading back out over the world from there.
Poor ASCII-art diagram:
backport Development --------> Release ^ ^ ^ ^ | \ _______/ / | \ / _____/ bugfixes feeder1 feeder2 / ^ ^ ^ ^ ^ / / |/ | \ / dev1 | dev3 dev4 dev2
(I tried to make a line from "dev2" into both feeder1 and feeder2 - the tree need not be a strict hierarchy. Dev2 can generate a change that gets pulled into both feeder1 and feeder2 and subsequently into Development with no confusion - if feeder2 gets pulled into Development first, the duplicate in feeder1 will be identified and "fast forwarded.")
HTH, gvb
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org <mailto:Koha-devel@nongnu.org> http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System ______________________________________________________________________ CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed.
______________________________________________________
Thank you for illuminating us on the ways of git ; ) It seems from you're description if there are lot's of Kyle's, that the likes of Chris and Paul are in for more work that previously. I, on the other hand, would be effected little. Thanks, Kyle On 3/16/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
Yes on the concepts, no on the level of effort. :-)
I'm not very familiar with koha's current VCS structure and methods since I'm not actively developing koha code (I installed koha at the private school that I donate my time too ;-) and only monitor the list for developments).
It sounds like there are several developers with write access to the master repo. This could be carried forward, but isn't the way git is being used elsewhere. Git is being used mostly as single-user per repo with the repos being available via http: or git: (preferably the latter). Hierarchy with single developers is an excellent way of providing scaling and preventing inadvertent interference.
Git background and tutorials: <http://git.or.cz/> <http://www.kernel.org/pub/software/scm/git/docs/tutorial.html> <http://www.kernel.org/pub/software/scm/git/docs/everyday.html>
The following is the concept, likely not 100% correct since I didn't actually execute the commands. It is also just one way of doing it (for example, pull is a fetch+merge - doing a fetch, inspect the potential changes, and then merge them has its benefits).
Kyle@kyle.com would have his repo and create New Code[tm]. He would either do this development in a new branch in his repo or would create a new branch for Chris: git checkout -b for_chris git pull . <commitID> (where <commitID> is his previously committed changes in his master branch) and email Chris "hey, pull for_chris".
Chris@chris.com would pull it into his repo by creating a temporary testing branch "from_kyle" and pulling the changes: git checkout -b from_kyle git pull git://kyle.com for_chris Chris tests the updates and likes them. He merges it into his mainline: git checkout master git pull . from_kyle and emails Josh "hey, pull "from_kyle".
Josh@koha.org does the equivalent, but, since he trusts Chris, doesn't bother creating a temporary branch for testing: git pull git://chris.com from_kyle
Some time later Chris and Kyle update their copies from koha.org: git pull at which time the changes that came from Chris will be fast forwarded and they can delete their respective branches Kyle: git branch -d for_chris Chris: git branch -d from_kyle
It really doesn't take much time because, by the time the changes bubble to the top, the trust and testing has been performed and the change just needs to be pulled. Since the pulls are just the changes, they are very quick.
Linus is doing this at the top level for linux with a handful of lieutenants (I don't know the current count, probably under 10). The number of active developers and changed lines of code is or should be way higher than what koha has. Linus isn't doing it full time, he still has time to rewrite portions of gnome. <http://www.linux.com/article.pl?sid=07/02/16/1937237> ;-) The git methodology scales well because it was designed from the ground up to be robust, efficient, and scalable.
gvb
I've been chatting with kados, and he suggested I get some feedback from Jerry.
It seems that if we switched to git we would need someone full-time just managing commits from the way I read Jerry Van Baren's post. It seems like the koha community, though dedicated, just isn't big enough to absorb the cost of losing development time to managing source code control. I doubt there are many programmers out there that would prefer to be managing the code they've written rather than writing more code ; )
What leads me to these conclusions is the whole hierarchy of 'pull' rather than push. It means that at each level of development, say me->chris->josh, everyone except the first person (me ) has to actively pull changes from the level below them. Please correct me if I am mistaken.
Kyle
On 3/16/07, *Jerry Van Baren* <gerald.vanbaren@smiths-aerospace.com <mailto:gerald.vanbaren@smiths-aerospace.com>> wrote:
Paul POULAIN wrote: > thinking of it, I was wondering wether a distributed VCS should be > considered as a "Release Manager" oriented VCS. > > I explain : unless i'm mistaken, it means : > - kados is the RM > - paul & chris are working on some feature > - paul "commit" the feature to kados repository, who will accept it (or > how is he warned that I made something ?) > - chris update his copy from kados one. > > iiuc, a D-VCS is in fact a RM-VCS to my mind. Thus the question : do we > have a RM that can afford that task/responsability ? > Once again, I may be mistaken, but i'm a little bit less enthusiasm if > i'm right...
This is where a D-VCS *really* shines (at least git, probably the others as well). The advantages of D-VCS is that you have not only branches but also replicated repositories to work with. The following is how things work with linux and git. It may apply to other D-VCS, but I don't know.
You have a development master repository. For linux, it is Linus Torvald's on kernel.org <http://kernel.org>. For Koha, this likely would be the 3.x development one. Only Paul Poulain (or whoever is the development master) does commits into this repo. Paul and Chris would have
Kyle Hall wrote: their
own feeder repos and _ask_ Paul to pull changes, they would not (normally) push changes into the RM repo.
The RM (Kados) also has a master repository. Bugfixes and also any backporting of new features get pulled into the repository by Kados. Pulls is the norm, pushes are generally not done.
You then have feeder repositories that the master maintainer (Paul
for
the development repo, Kados for the release repo) pulls improvements from after they've been vetted. This would be Paul & Chris &
everybody
else in a hierarchy.
All the koha developers then have their local working repository,
which
is a clone of the master + "value added". In the local repository,
they
pull changes from the master RM repo to keep up to date, as well as doing their local work. If another feeder repo has a change they want/need, they can pull that change directly from the feeder repo (including "cherry-picking" changes). Since git keeps track of
changes
by their hash name, when the master RM repo picks up a feeder's
change,
the local repos that already have that change just say "been there,
done
that, fast forward" and life is good. Otherwise a merge is done and life is still good (except for a collision, but that is unavoidable
and
is no different than what happens with CVS/SVN).
Local changes are source controlled in the local repo - something
I've
never succeeded in doing well with CVS/SVN, but is transparently trivial with git. When a local change is considered ready for inclusion, by convention a branch is created in the local repo with a distinctive
name
and the appropriate upstream repo owner is notified (traditionally
by
posting a patch on the developers' email list so everybody can
review
the change). The upstream repo owner then pulls the change into the upstream repo, ultimately ending up in the master RM repo (or the
"new
HEAD" repo) and spreading back out over the world from there.
Poor ASCII-art diagram:
backport Development --------> Release ^ ^ ^ ^ | \ _______/ / | \ / _____/ bugfixes feeder1 feeder2 / ^ ^ ^ ^ ^ / / |/ | \ / dev1 | dev3 dev4 dev2
(I tried to make a line from "dev2" into both feeder1 and feeder2 -
the
tree need not be a strict hierarchy. Dev2 can generate a change
that
gets pulled into both feeder1 and feeder2 and subsequently into Development with no confusion - if feeder2 gets pulled into
Development
first, the duplicate in feeder1 will be identified and "fast forwarded.")
HTH, gvb
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org <mailto:Koha-devel@nongnu.org> http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System ______________________________________________________________________ CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed.
______________________________________________________
-- IT Tech Crawford County Federated Library System
On Fri, Mar 16, 2007 at 03:04:30PM -0400, Kyle Hall said:
Thank you for illuminating us on the ways of git ; ) It seems from you're description if there are lot's of Kyle's, that the likes of Chris and Paul are in for more work that previously. I, on the other hand, would be effected little.
Speaking as Chris I don't think this is nessecarily a bad thing, a bit more checking as code comes in can save a bunch of time in the future. I guess what I'm saying is we should be doing something like this currently anyway, at least we should be sanity checking code as its committed. We wouldnt end up with dual implementation of the same feature, and some of the duplicate code we now have. Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
I think everyone would agree that more checking of code is good. As long as you and Paul and Josh are willing to put in a bit more time, I imagine everyone will be all for it. I think the big question is *how much* more time will it require from you guys. I think only the people currently using git will be able to help us answer us. Kyle On 3/16/07, Chris Cormack <chris@katipo.co.nz> wrote:
On Fri, Mar 16, 2007 at 03:04:30PM -0400, Kyle Hall said:
Thank you for illuminating us on the ways of git ; ) It seems from you're description if there are lot's of Kyle's, that the likes of Chris and Paul are in for more work that previously. I, on the other hand, would be effected little.
Speaking as Chris
I don't think this is nessecarily a bad thing, a bit more checking as code comes in can save a bunch of time in the future. I guess what I'm saying is we should be doing something like this currently anyway, at least we should be sanity checking code as its committed. We wouldnt end up with dual implementation of the same feature, and some of the duplicate code we now have.
Chris
-- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
-- IT Tech Crawford County Federated Library System
Well, it is hard to be definitive without a clue of your current development methodologies, but I would speculate that it will take somewhere from little more to a lot less time than CVS/SVN with multiple writers (note that you can still have multiple writers with git, it just is not generally useful since everybody has their own copy of the repository). If the code in CVS never gets messed up because of multiple people committing incompatible changes, it will take minimal extra time for everybody upstream to pull changes. On the other hand, if ever you get a mess due to multiple people committing incompatible stuff in CVS, you've just saved every bit of time that the extra pulling cost. I suspect this has already happened at least once. :-/ I tried to outline a "pull" scenario in a previous email to illustrate that it is NOT painful. Doing a pull is a single command you run that takes seconds to run and you do it occasionally (on demand, when you feel like it, once a day, once a week, whatever makes sense). It is the same level of effort as doing a "svn update". In addition, if you use local source control (maintaining a local copy of the cvs/svn repository to track local changes or using RCS locally) *which all developers should do*, git is a huge improvement. All of the developers will benefit (save time) with git, so the net time savings equation is positive, regardless. There is a learning curve to climb, but it isn't very steep and the rewards are pretty good. RCS - gets the job done but cannot share the changes CVS - gets the job done over the wire, allowing sharing (Pinto) SVN - puts a turbocharger in the Pinto (Pangra) git - everybody makes their own clone of the Lamborghini Reference pointers for the non-US residents (and youngsters ;-): <http://en.wikipedia.org/wiki/Ford_Pinto> <http://en.wikipedia.org/wiki/Supercar> Best regards, gvb Kyle Hall wrote:
I think everyone would agree that more checking of code is good. As long as you and Paul and Josh are willing to put in a bit more time, I imagine everyone will be all for it. I think the big question is *how much* more time will it require from you guys. I think only the people currently using git will be able to help us answer us.
Kyle
On 3/16/07, *Chris Cormack* <chris@katipo.co.nz <mailto:chris@katipo.co.nz>> wrote:
On Fri, Mar 16, 2007 at 03:04:30PM -0400, Kyle Hall said: > Thank you for illuminating us on the ways of git ; ) > It seems from you're description if there are lot's of Kyle's, that the > likes of Chris and Paul are in for more work that previously. I, on the > other hand, would be effected little. > Speaking as Chris
I don't think this is nessecarily a bad thing, a bit more checking as code comes in can save a bunch of time in the future. I guess what I'm saying is we should be doing something like this currently anyway, at least we should be sanity checking code as its committed. We wouldnt end up with dual implementation of the same feature, and some of the duplicate code we now have.
Chris
-- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz <mailto:chris@katipo.co.nz> www.katipo.co.nz <http://www.katipo.co.nz>
-- IT Tech Crawford County Federated Library System ______________________________________________________________________ CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed.
______________________________________________________
Thanks for the extra information. Just on a technical note, let's say I e-mail you and say 'pull the changes I've made from my local repository into yours', this means that I have to have my work pc publicly available. I assume that git has a certain port it works on. Is that correct? Kyle On 3/19/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
Well, it is hard to be definitive without a clue of your current development methodologies, but I would speculate that it will take somewhere from little more to a lot less time than CVS/SVN with multiple writers (note that you can still have multiple writers with git, it just is not generally useful since everybody has their own copy of the repository).
If the code in CVS never gets messed up because of multiple people committing incompatible changes, it will take minimal extra time for everybody upstream to pull changes.
On the other hand, if ever you get a mess due to multiple people committing incompatible stuff in CVS, you've just saved every bit of time that the extra pulling cost. I suspect this has already happened at least once. :-/
I tried to outline a "pull" scenario in a previous email to illustrate that it is NOT painful. Doing a pull is a single command you run that takes seconds to run and you do it occasionally (on demand, when you feel like it, once a day, once a week, whatever makes sense). It is the same level of effort as doing a "svn update". In addition, if you use local source control (maintaining a local copy of the cvs/svn repository to track local changes or using RCS locally) *which all developers should do*, git is a huge improvement.
All of the developers will benefit (save time) with git, so the net time savings equation is positive, regardless. There is a learning curve to climb, but it isn't very steep and the rewards are pretty good. RCS - gets the job done but cannot share the changes CVS - gets the job done over the wire, allowing sharing (Pinto) SVN - puts a turbocharger in the Pinto (Pangra) git - everybody makes their own clone of the Lamborghini
Reference pointers for the non-US residents (and youngsters ;-): <http://en.wikipedia.org/wiki/Ford_Pinto> <http://en.wikipedia.org/wiki/Supercar>
Best regards, gvb
Kyle Hall wrote:
I think everyone would agree that more checking of code is good. As long as you and Paul and Josh are willing to put in a bit more time, I imagine everyone will be all for it. I think the big question is *how much* more time will it require from you guys. I think only the people currently using git will be able to help us answer us.
Kyle
On 3/16/07, *Chris Cormack* <chris@katipo.co.nz <mailto:chris@katipo.co.nz>> wrote:
On Fri, Mar 16, 2007 at 03:04:30PM -0400, Kyle Hall said: > Thank you for illuminating us on the ways of git ; ) > It seems from you're description if there are lot's of Kyle's, that the > likes of Chris and Paul are in for more work that previously. I, on the > other hand, would be effected little. > Speaking as Chris
I don't think this is nessecarily a bad thing, a bit more checking as code comes in can save a bunch of time in the future. I guess what I'm saying is we should be doing something like this currently anyway, at least we should be sanity checking code as its committed. We wouldnt end up with dual implementation of the same feature, and some of the duplicate code we now have.
Chris
-- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz <mailto:chris@katipo.co.nz www.katipo.co.nz <http://www.katipo.co.nz>
-- IT Tech Crawford County Federated Library System ______________________________________________________________________ CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed.
______________________________________________________
-- IT Tech Crawford County Federated Library System
Yes, for a pull to happen, the repository must be publicly accessible (i.e. on the internet). The best way is via the git port 9418, the other way is via port 80 using http: (I presume 443 https: works too, have not tried). Unfortunately, many IT departments block all ports except 80 and 443 (including ssh, grrrrr). Depending on what an individual developer has to work with (what the IT department provides for access), publishing a local repository can be difficult or impossible. Pushing is generally (exclusively?) done via ssh so unenlightened/uncooperative IT departments can be a problem for pushing as well (cvs/svn have the same problem). What Wolfgang Denk did for u-boot is to set up a bunch of feeder repositories on his company's server and give the feeder developers ssh access so that they could push their local repositories to the main server, at which point the world can pull from the main repository and any feeder repositories that they need. <http://www.denx.de/wiki/UBoot/Custodians> I presume that is similar to what the primary linux kernel developers have on <http://git.kernel.org/>, but better organized. The u-boot feeder repositories is a fairly new development. It has been working well so far... Having all the feeder repositories collected in one place for ease of reference is ideal. Since git is a distributed SCM, all your eggs are in everybodys' baskets (repo clones) so this is not a problem. Obviously, this takes some effort to set up and a host (like koha.org) to run it on. HTH, gvb Kyle Hall wrote:
Thanks for the extra information. Just on a technical note, let's say I e-mail you and say 'pull the changes I've made from my local repository into yours', this means that I have to have my work pc publicly available. I assume that git has a certain port it works on. Is that correct?
Kyle
On 3/19/07, *Jerry Van Baren* <gerald.vanbaren@smiths-aerospace.com <mailto:gerald.vanbaren@smiths-aerospace.com>> wrote:
Well, it is hard to be definitive without a clue of your current development methodologies, but I would speculate that it will take somewhere from little more to a lot less time than CVS/SVN with multiple writers (note that you can still have multiple writers with git, it just is not generally useful since everybody has their own copy of the repository).
If the code in CVS never gets messed up because of multiple people committing incompatible changes, it will take minimal extra time for everybody upstream to pull changes.
On the other hand, if ever you get a mess due to multiple people committing incompatible stuff in CVS, you've just saved every bit of time that the extra pulling cost. I suspect this has already happened at least once. :-/
I tried to outline a "pull" scenario in a previous email to illustrate that it is NOT painful. Doing a pull is a single command you run that takes seconds to run and you do it occasionally (on demand, when you feel like it, once a day, once a week, whatever makes sense). It is the same level of effort as doing a "svn update". In addition, if you use local source control (maintaining a local copy of the cvs/svn repository to track local changes or using RCS locally) *which all developers should do*, git is a huge improvement.
All of the developers will benefit (save time) with git, so the net time savings equation is positive, regardless. There is a learning curve to climb, but it isn't very steep and the rewards are pretty good. RCS - gets the job done but cannot share the changes CVS - gets the job done over the wire, allowing sharing (Pinto) SVN - puts a turbocharger in the Pinto (Pangra) git - everybody makes their own clone of the Lamborghini
Reference pointers for the non-US residents (and youngsters ;-): <http://en.wikipedia.org/wiki/Ford_Pinto> < http://en.wikipedia.org/wiki/Supercar>
Best regards, gvb
Kyle Hall wrote: > I think everyone would agree that more checking of code is good. As long > as you and Paul and Josh are willing to put in a bit more time, I > imagine everyone will be all for it. I think the big question is *how > much* more time will it require from you guys. I think only the people > currently using git will be able to help us answer us. > > Kyle > > On 3/16/07, *Chris Cormack* <chris@katipo.co.nz <mailto:chris@katipo.co.nz> > <mailto:chris@katipo.co.nz <mailto:chris@katipo.co.nz>>> wrote: > > On Fri, Mar 16, 2007 at 03:04:30PM -0400, Kyle Hall said: > > Thank you for illuminating us on the ways of git ; ) > > It seems from you're description if there are lot's of Kyle's, > that the > > likes of Chris and Paul are in for more work that previously. I, > on the > > other hand, would be effected little. > > > Speaking as Chris > > I don't think this is nessecarily a bad thing, a bit more checking as > code comes in can save a bunch of time in the future. I guess what I'm > saying is we should be doing something like this currently anyway, at > least we should be sanity checking code as its committed. We wouldnt > end up with dual implementation of the same feature, and some of the > duplicate code we now have. > > Chris > > > -- > Chris Cormack > Programmer > 027 4500 789 Katipo > Communications Ltd > chris@katipo.co.nz <mailto:chris@katipo.co.nz> > <mailto:chris@katipo.co.nz <mailto:chris@katipo.co.nz>> www.katipo.co.nz <http://www.katipo.co.nz> > < http://www.katipo.co.nz> > > > > > -- > IT Tech > Crawford County Federated Library System > ______________________________________________________________________ > CAUTION: This message was sent via the Public Internet and its > authenticity cannot be guaranteed. > > ______________________________________________________
-- IT Tech Crawford County Federated Library System ______________________________________________________________________ CAUTION: This message was sent via the Public Internet and its authenticity cannot be guaranteed.
______________________________________________________
"Kyle Hall" <kyle.m.hall@gmail.com> wrote:
[...] this means that I have to have my work pc publicly available. I assume that git has a certain port it works on. Is that correct?
The other email gives details about the git server ways, but you can mirror your git repository to an http site or whatever you can get access to. Alternatively, there are git commands which bundle your changes up into an email. If you can publish web space or send email, you can share your changes in some way. It's at least as possible as CVS or SVN. Maybe more so. Hope that helps, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Webmaster/web developer, statistician, sysadmin, online shop maker, developer of koha, debian, gobo, gnustep, various mail and web s/w. Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/
Well, I think git is the way to go. The repo can be initially set up to accept pushes from any number of developers, but can then be restricted so as to force code audit before commits. With the increased flexibility in maintaining local code modifications and other features, git gets my vote. rch Ryan Higgins ----LibLime---------------------------------- Providing Open-Source Solutions for Libraries Migration, Training, Maintenance and Support Featuring Koha ILS : http://liblime.com/koha --------------------------------------------- ----- "MJ Ray" <mjr@phonecoop.coop> wrote: | "Kyle Hall" <kyle.m.hall@gmail.com> wrote: | > [...] this means that I have to have my work pc publicly available. | I | > assume that git has a certain port it works on. Is that correct? | | The other email gives details about the git server ways, but you can | mirror your git repository to an http site or whatever you can get | access to. Alternatively, there are git commands which bundle your | changes up into an email. If you can publish web space or send | email, | you can share your changes in some way. It's at least as possible as | CVS or SVN. Maybe more so. | | Hope that helps, | -- | MJ Ray - see/vidu http://mjr.towers.org.uk/email.html | Webmaster/web developer, statistician, sysadmin, online shop maker, | developer of koha, debian, gobo, gnustep, various mail and web s/w. | Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/ | | | _______________________________________________ | Koha-devel mailing list | Koha-devel@nongnu.org | http://lists.nongnu.org/mailman/listinfo/koha-devel
participants (15)
-
Antoine Farnault -
Chris Cormack -
Cindy Murdock -
Dan Scott -
Jerry Van Baren -
Joshua M. Ferraro -
José Miguel Parrella Romero -
Kyle Hall -
MJ Ray -
Nathan Gray -
Owen Leonard -
Paul POULAIN -
Paul_Shannon -
Pierrick LE GALL -
Ryan Higgins