Re: [ jEdit-devel ] Git Hook for Core and Plugins and Git transition of Core

[Vampire <Vampire@jEdit.org>]

Ok, SVN trunk and branches are back in place for now.

Cheers
Björn

Am 30.08.2013 00:28, schrieb Vampire:
> Hi all,
>
> I already had everything finished and was about to post about the success when I saw Ross' mail about the file that shouldn't be there.
> Unfortunately this made me look further and it seems that somewhere during the migration steps something went badly wrong.
>
> There are files that were deleted during SVN commits that did not get deleted in the according Git commits and thus were still around in trunk and the branches, there are badly broken commits like http://jedit.git.sourceforge.net/git/gitweb.cgi?p=jedit/jEdit.bak;a=blobdiff;f=org/gjt/sp/jedit/search/SearchDialog.java;h=ce3dbec32dceb4dc63b790fcd7fd8494944886fa;hp=1ad756b7ea325176fedc5a7196f5086a29d0cb24;hb=fa6b414388544537e29dc2f8ba4268f8da67f1a1;hpb=5feed197586f27396d597967b15b1fb91e785cc7 which actually should have been a one liner: http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/org/gjt/sp/jedit/search/SearchDialog.java?r1=5308&r2=5309&pathrev=23149.
>
> So I have to look further into this, see what went wrong or do it again correctly and then do the switch again.
> But this will cost me some time, so for now the switch is delayed and I'm right now reinstantiating the SVN trunk and branches.
>
> Regards
> Björn
>
>
> Am 16.08.2013 00:30, schrieb Vampire:
>> Hi guys,
>>
>> I want to finally finish the Git transition of the Core.
>> I prepared everything for it and basically just have to make SVN read-only, migrate newly added commits since the last sync I did a few days ago, activate the post-receive script that sends mails to the mailing list and open up the repo for push as it is currently only opened for push by me.
>>
>> So I'd say, I give you guys a good week to prepare and possibly to last checkins before the transition and will do the final switch on next weekend August 24./25., except someone says it should be delayed a bit or everyone says it could be done earlier.
>>
>> As a reminder for those who forgot, with this transition we also have a mostly complete history of jEdit, back until version jEdit-0.2-19980927, including SF SVN History, SF CVS History, GJT CVS History and a couple of folders that were just laying around on Slava's harddrive. :-)
>>
>>
>>
>> Besides the pure transition and combination of the jEdit VCS', I also created a pre-receive script that will be in effect on Core and that I will also install to the already existing plugin repositories. Newly created ones will already have it.
>>
>> This pre-receive script has basically two duties, housekeeping and safekeeping.
>>
>> Housekeeping means that it checks the committer name and email.
>> I'd like to prevent that one user uses various identities to commit stuff.
>> Also this is usually not intentionally, but e. g. you have one email set in global Git config, but want to use another one for SF stuff, e. g. the SF address. But this means you always have to remember that you have to change the mail address after doing a fresh clone for whatever reason. I caught myself multiple times forgetting to do so.
>>
>> So, the housekeeping part of the script verifies that the committer name bears at least firstname and lastname and not just some nick and the email address has to be the lowercase SF net mail address, e. g. vam...@us... for me myself. This way one user should always use the same identitiy as long as he does not pretend committing as some other user. The author information is not checked, but freely settable, e. g. for patches that come from the community, so the Author can get correct appreciation. :-)
>>
>> The second part of the script is safekeeping and thus adds a feature I missed since we switched from CVS to SVN because SF didn't get it managed to install a simple hook many users asked for.
>> You can control who can push to a repo on ref and repo level. You can have a file called .gitaccess in the root of your source tree. Empty lines and lines starting with arbitrary whitespace followed by a hash character ("#") are ignored. All other lines, stripped by leading and trailing whitespace are SF usernames of users that are allowed to push to the ref where the .gitaccess file is present. If a ref has no .gitaccess file, the one from the ref called "master" is used instead. If there is also no .gitaccess file, everyone with basic access is allowed to push to that repo. Likewise will an empty .gitaccess file block push access completely from all users.
>>
>> As a safety precaution, you cannot push a rev to a ref that takes away push allowance from yourself the first time you try. You have to repush the very same rev to the ref within 24 hours if that is really what you want to do which you cannot undo without my help.
>>
>> As a second safte precaution, pushes that remove a .gitaccess file are also not allowed on the first try, but only on the second try within 24 hours to push the same rev to the ref.
>>
>> On the first 10 push attempts - no matter whether successful or not - the script will also advertise its possibilities to restrict push allowance to the pusher.
>>
>>
>>
>> I hope you like those changes. :-)
>>
>> Cheers
>> Björn
>>