Comments inline...
Le 05/08/2017 à 09:22, Brian Burch a écrit : > On 04/08/17 18:16, Emmanuel Lécharny wrote: >> Hi guys, >> >> >> "It was the best *of* times, it was the worst *of* times" (Dickens) >> >> >> it's a pretty big change : switching away from SVN to git. We are using >> svn from the very beginning, so to speak 14 years, and it's probablu >> time to use a more efficient and modern VCC system. To most of you, that >> should be a no brainer, and we already have a few sub-projects using git >> at Diectory (Fortress, kerby). >> >> >> However, I think it's important to get this vote out, as it's gong to >> impact the project as a whole. >> >> >> Note that it will just be for teh API atm, but the other projects will >> most certainly migrate sooner or later (ApacheDS, Studio, Mavibot and >> teh site) >> > > I'm just a dinosaur! Ah ! And you are not alone :-) Born in 1964, I can tell you that I'm closer to the end of my carrer than the opposite... > > Some of my dormant projects are still held on CVS (to retain the > history)! I made the switch to SVN for those projects which required > it and adapted my methods to suit. As time went by I began to > appreciate the value in the weaknesses of CVS which were addressed by > SVN. I am comfortable with SVN, warts and all... When I was a student, working on MS-DOS machines, we didn't have access to any VCS. When I started to work I faced SCCS (https://en.wikipedia.org/wiki/Source_Code_Control_System) and my first internship was about creating a shells script based interface that make it transparent for users : operations like 'edit <file>' were pulling the latest version of teh file, and 'save <file>' was pushing it back to the repo. It was in 1988... Then I switched to Microsoft SourceSafe (a huge improvement !), moved back to Clear Case (a clear regression, up to a point we needed a dedicated person to merge the changes :/). Then I switched to CVS, which was OK, but asI was also working in Java and specifically with IBM VisualAge (https://en.wikipedia.org/wiki/IBM_VisualAge) - which aged no so well... - that included a VCS (that saved us many times). Except that sharing the changes in the team wasn't that easy. In 2005, when I started working on Directory, it was already using SVN (The ASF migrated from CVS to SVN around 2003,AFAICT). A huge plus compared to CVS especially when it comes to manage branches ( I hated so much the way branches were managed in CVS :/). SVN was not perfect, and in old versions, managing branches and merging was quite a nightmare ! It improves with the years, and especially the plugins for the IDE we are using (Eclipse), but we were years before being able to commit from teh IDE (during a couple of years we were mostly committing from the command line). So SVN is now stable, well known by people working on this project for more than a decade. But... (see later comments) > > Of course, I've had to work with GIT when a project has converted, and > I've heard all the advocates many times before. It must be my > fossilised brain making me still uncomfortable with GIT - it just > feels "back to front" to me. In my mind, it feels natural to have an > authoritative source and replicate it into my own "sandbox" to "play" > with. Actually, we do have a authoritative source at The ASF : the code is stored on an ASF machine, because The ASF is taking responsability to provide code to the public. All in all, the way The ASF uses git is a bit different to what other organisations are used to. I also have to say that The ASF was quite relictant to use Git for good - and bad - reasons. Nowadays, I would say that 75% of the ASF projects are using GIT, and I don't know of ny new projects using SVN today. Anyway, I know your feelings : I'm myself so used with SVN that everytime I have to switch to git - and all the cryptic command lines options - it's a bit of a pain. OTOH, I realized that I have to work more and more with git those days, and it's now a pain to have to switch frm git to SVN and from SVN to git :/ And this is the whole idea : getting rid of this mental charge. > > I've noticed all the enthusiastic +1's for this vote, so I am resigned > to having to adapt to yet another GIT project. All I can ask is that > someone writes a helpful wiki page for those developers who want to > hit the ground running once the trunk has migrated. Will there be any > gotchas associated with the transitional period? Yes, we will need to write down a page about the migration. And there will be gotchas : - SVN ignores will have to be converted to .gitignore - our build is based on externals and I'm no sure we can have the same in git. OTOH, I'm not sure it makes sense anymore t use externals... - PRs will have to be handled, while we were mostly asking people to attach a diff to a JIRA when they wanted to propose a patch. > >> So : >> >> >> [ ] +1 : switch Apache LDAP API to git >> >> [ ] +/-0 : I don't mind >> >> [ ] -1 : Keep going with SVN >> >> >> -1 is not a veto, feel free to speak your mind. The idea is to be sure >> we are all on the same page here : I don't feel compelled to switch, but >> I do think it would make it easier for us to work on the project, and >> for external users to push PRs. > > Thanks for being so diplomatic, Emmanuel. With your "encouragement", I > am inclined to vote -1... > > However, if someone can explain how the peculiar SVN structure of the > project would be improved by migration to GIT - I mean having to > checkout the code and wiki sources under different urls and sandboxes, > then I would be happy to vote +1. As I said we are using externals, which allows you to checkout many projects in one shot doing : svn co http://svn.apache.org/repos/asf/directory/trunks which pulls apacheds, studio, shared, project, kerberos-client, checkstyle-configuration, junit-addons, apacheds-manuals, ldap-api-manuals, jdbm, mavibot, skin and docker. Out of those projects, a few might die sooner or later : apacheds-manuals, ldap-api-manuals and jdbm. Otherwise, git has submodules that pretty much mimic svn:externals. Beside that, we already have a decent git support in most of the IDE, Git is way faster when it comes to commit huge changes, and makes it simpler to merge changes when some directory or files are moved around - SVN tree merge nightmare anyone ? ;-) -. > > I am pleased to see everyone voting so politely! Why would we behave differently ? I know that Game Of Throne 7 is out, but that's better on a TV set than in real life ;-) Have a nice week-end ! -- Emmanuel Lecharny Symas.com directory.apache.org
