tags:

views:

39

answers:

1

I'm new to GIT and I'm having long thoughts about how to use GIT to manage my projects structured as below.

CODE1
L .metadata
L appleserver
L shared-code-archive = common with bananaserver
L logger-archive = common with bananaserver

CODE2
L .metadata
L bananaserver
L shared-code-archive = common with appleserver
L logger-archive = common with appleserver

The .metadata is the Eclipse metadata and is project specific to appleserver or bananaserver. appleserver has project specific code and is versioned as 1.0, 1.1 etc shared-code-archive is shared code, and has its own versioning as 1.0, 1.1 etc. logger-archive is shared code, and has its own versioning as 1.0, 1.1 etc.

Appleserver ver 1.0 depends on ver 1.5 shared-code-archive, and ver 1.3 of logger-archive. Appleserver ver 1.1 depends on ver 1.6 shared-code-archive, and ver 1.3 of logger-archive.

I need to be able to manage appleserver project such that, when I checkout version 1.0 of apple server, I need the dependent versions to get checked out automatically.

+1  A: 

As they have their own versioning, they seem like independent projects. I personally would have "shared-code-archive" and "logger-archive" be separate repositories, and include the correct version of compiled libraries in a lib folder of CODE1 and CODE2. When you need to update, pull in the new version of the library and check it in (after running unit tests, of course). In my mind, these can be treated like any 3rd party library or artifact. If you need the source to "logger-archive" 1.2, go get it from the logger-archive repo.

Philip Rieck