Re: [VuFind-Tech] Vufind 2.0 and git

[Katharina W. <wol...@fh...>]

Hi Henri-Damien,

thanks for all your tips and links concerning git.

I'll have a look at them as soon as possible and maybe at some point in the
future I'll be able to write a wiki-page for vufind 2.0 myself. ;-)

The main problem I have with all the git-books and -online-documentations is,
that they all start with describing how to use git with a local repository on
either a linux server or in case of TortoiseGit on a windows-PC with a local
user etc. etc.

Using git with a distributet and share repository-structure with linux-server-
and windows-client-interaction is dealt with in a chapter very late in the book
and - at least for me - mostly very hard to understand.

Finding understandable documentation on using git for
vendor-repository-/local-development-repository-interaction like I need for our
vufind-2.0-server or -windows-clients is even harder.

And because those rather specialised questions where very hard for me to answer
with SVN resulting in my going about things the wrong way or in the wrong order
of steps, I want to understand as much beforehand as possible.

Thanks again
Kate

Am 05.07.2012 09:33 schrieb Henri-Damien LAURENT:
> Hi Kathrina,
> I am not involved in the vufind project,
> But since your question has much more to do with DVCS and especially git
> rather than with the vufind project, and I know and practise git for
> Koha ILS, I will try to bring you some information.
> 
> You may use hooks in git so that you can create post-commit. (I don't
> know though if you can just run a powershell script, but since it is
> only the name of the hook and its property, executable or not that is
> involved, I would guess it could be ok)
> http://git-scm.com/book/ch7-3.html
> man page :
> http://www.kernel.org/pub/software/scm/git/docs/githooks.html
> 
> 
>> (to answer your question 
>> could anyone of you write a wiki-page for vufind 2.0 that explains
> how-to go
>> about setting up the git-equivalent of the
>> SVN-vendor-branch/-local-branch-construct on a linux-server so one
> will be able
>> to merge developments from the public trunk into one's own local
> developments
>> without having to manually compare each file and manually merge the
> differences?)
> You may also take a look at that page :
> http://wiki.koha-community.org/wiki/Version_Control_Using_Git
> 
> git diff shows you differences not commited on the current working
> directory, (but also much more look at git diff man page).
> git merge helps you merge branches when you need that.
> 
> You can take a look at gitimmersion ( http://gitimmersion.com/ ) and
> Progit book ( http://git-scm.com/book/ ).
> 
> I don't know whether a wiki page is needed, or if it should just contain
> those pointers. The Vufind community may consider sharing specific
> git-hooks in order to ease the process of maintenance and contribution.
> But it would be another step I think.
> 
> Hope that helps.
>  
> 
> Le mercredi 04 juillet 2012 à 12:39 +0200, Katharina Wolkwitz a écrit :
>> Hi everybody,
>>
>> since I want to avoid the hassel I had when I started with vufind and was
>> confronted with SVN, this time I'd like to take the neccessary steps in the
>> right order and thus also avoid having to litter this mailing list with a lot of
>> newbie-mails.
>>
>> At the moment I'm preparing a new virtual server for vufind 2.0
>> I decided to use a different machine, so there are no possible version-conflicts
>> at all.
>>
>> The server will be run under SLES 11 SP2 (at the moment it's still on SP1, but
>> the upgrade is planned for tomorrow afternoon). I know that using SLES has
>> disadvantages when trying to install software in a version that's not offered
>> via Yast, but as up to now all my servers are running under SLES that the
>> environment I'm most used to.
>>
>> The requirements for vufind 2.0 are:
>> - PHP 5.3.3 (or newer)
>>
>> (the following requirements are taken from
>> http://vufind.org/wiki/vufind_on_linux which deals with vufind 1.x)
>>
>> - Apache 2.2 (with mod_rewrite)
>> - MySQL (I guess any current version would suffice?)
>> - Java JDK
>>
>> Is that correct so far?
>>
>> Another requirement is git (in order to get the vufind 2.0-software and also as
>> a version-controll-system for the local project). Now here I've got a huge
>> favour to ask from those already savvy in using, installing and setting up git
>> as a version-control-system:
>> could anyone of you write a wiki-page for vufind 2.0 that explains how-to go
>> about setting up the git-equivalent of the
>> SVN-vendor-branch/-local-branch-construct on a linux-server so one will be able
>> to merge developments from the public trunk into one's own local developments
>> without having to manually compare each file and manually merge the differences?
>>
>> An added bonus would be a how-to use a linux-server as a basis for running
>> vufind with using Windows-7-PCs as development "workstations".
>>
>> I now there's a tortoise-git and also a notepad++-addon (which I'm mighty glad
>> of), but since it took me quite a while to get the SVN-connections between the
>> working-copies on the Windows-systems and the SVN-base on the server up and
>> running, so that different developers can use git without having their own
>> different ssh-login on the server.
>> I've found how to do that with SVN here: http://tortoisesvn.net/ssh_howto.html
>>
>> As far as I know, git doesn't really need the centrally-based structure SVN has,
>> but since I need the following thing to work, I really hope, someone will be
>> able to add a how-to or at least links for it to the vufind-documentation on git:
>>
>> I need a way to get all modifications done on the windows-"clients" to be put
>> into the (hopefully also version-controlled) running-directory of my
>> vufind-installation on the server (/usr/local/vufind), so that we can see how
>> the changes work out on our browsers.
>> In SVN I mangaged that through a poss-commit-hook-script similar to the
>> description here:
>> https://www.zulius.com/how-to/automatically-update-a-subversion-working-copy-on-commit/
>>
>> I hope that this mail is neither too long nor too short, still understandable
>> and someone is willing to write the documentation into the wiki. :-)