directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: [Vote] Switch to git for Apache LDAP API 2.0
Date Mon, 07 Aug 2017 10:31:26 GMT
This will probably mess up the thread, but I accidentally sent it only 
to Emmanuel when I meant to reply to the list!

Sorry for shooting from the hip..

On 05/08/17 20:24, Emmanuel Lécharny wrote:
> 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
> ( 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 ( - 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
> 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 !

Thank you very much for your long and interesting explanation, Emmanuel.

I won't bore you with my own long list of past experiences, but they are 
rather similar to yours (except I started on mainframes)! I especially 
appreciated your final svn-to-git section, because I haven't needed to 
gain that experience until now.

I am not one to leap into the dark without a plan, so it was very 
illuminating to be told why that would not be the case for the Directory 
project. I hope your explanation will prove to be interesting to other 
readers in the future, especially if they are confronting the same 
conversion issues for a different project.

I am considerably wiser now, and delighted to change my vote...


Thanks again,


p.s. I will follow the migration process with interest - especially the 

View raw message