Installation Plan

Installation Plan

[Dennis Putnam]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

After re-reading the git documentation and with Andrew's input I have
changed my thinking on how to set  this up and want a central
repository. If I understand correctly, I am doing builds while I am
developing new code so I need to clone my repository for Eclipse (I'm
assuming the git plugin supports all this). Before I go to the trouble
of setting it up please correct where my thinking is flawed or where I
may run into gotchas.

1) Install git on Linux.
2) Copy existing Eclipse project to a new directory to become the
central repository.
3) git init in that new directory (I think I then do a git add and git
commit).
4) Modify build scripts to build from that directory (I am guessing I
need to git ignore the javac generated binary directory).
5) Install git plugin on Windows version of Eclipse. (Do I need git on
Windows or is the plugin sufficient?)
6) Configure plugin for remote git, if necessary?
7) Clone new repository for development and testing on Windows. (Do I
need the shared drive any more?)
8) When a new version is ready for release, push commit to remote
repository after which builds will use new code (I'm assuming the file
copies happen automagically).

Am I over simplifying things? I also think that this will open the door
for collaborators in the event I need them with no changes to the way I
work. I should note that builds are done on demand so is there a way to
detect when a push is occurring and have the build script wait for
completion and I suppose vise-versa? Thanks.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Installation Plan

[Andrew Ardill]

hi Dennis,

In general your plan looks good. Note that you don't actually need the
Eclipse plugin at all, it just makes it possible to do git operations
while in your IDE. Most people will, even if they have the plugin,
still use the full client as it provides a lot more power and
flexibility. Use whatever you need to, and extend your toolset when
required.

Also, the leap from central repository on Linux to a clone on Windows
needs a little more thought. Will you set up a git server? Access the
central repository over ssh? A shared drive? Many people use a web
service (such as Bitbucket or GitHub) for this purpose as it becomes
easier to manage. You can then have a clone on the Linux box as well
as the Windows box.

On 22 December 2012 01:43, Dennis Putnam <dap1@bellsouth.net> wrote:
> Am I over simplifying things? I also think that this will open the door
> for collaborators in the event I need them with no changes to the way I
> work. I should note that builds are done on demand so is there a way to
> detect when a push is occurring and have the build script wait for
> completion and I suppose vise-versa?

You want to look into the different hooks available, most notable the
post-receive hook. There are also build servers that can monitor a
repository and build whenever it sees a new commit (Jenkins and Bamboo
are two I know of).

Regards,

Andrew Ardill

Re: Installation Plan

[Enrico Weigelt]

> 7) Clone new repository for development and testing on Windows. (Do I
> need the shared drive any more?)

Not necessarily, depending on how to connect your local repo to the
remote one (your central repo). I'd suggest using ssh protocol: in this
case your windows box will connect to the linux box via ssh and do all
operations via ssh - no network filesystem required.

> 8) When a new version is ready for release, push commit to remote
> repository after which builds will use new code (I'm assuming the
> file copies happen automagically).

Yes, see post-update hook (on the central repo side).
It is executed right after objects have been transfered and refs updated.
(IOW: when your changes made finally it into the cental repo).
Note that the 'git push' operation will wait until that hook is finished.
So, if the build takes a while, you most likely want to do it asychronously.
A nice way is letting the hook just add the new refs to some queue
(you can even use git refs for that) and have another process (in a loop
or via cron) polling for new queue entries and run the build.


cu
-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Mobile: +49 (151) 27565287
Fax: +49 (30) 3464615-59

enrico.weigelt@vnc.biz; www.vnc.de