> I'm about to migrate a large project which is currently managed in subversion 
> to git. Git experience is still limited. Besides wonder frameworks, the 
> project consists of
> 
> - one application
> - several frameworks that are more or less specific to the application
> - several more generic frameworks that we use throughout the company in a 
> number of apps.
> 
> In subversion, all those are separate projects but on the same svn server. 
> This enables commits spanning the app itself and all affected frameworks, for 
> example to encapsulate one change that changes the API of a framework and 
> adapts the app to that API change at the same time.
> 
> What would the git freaks among you recommend as a repo layout for that?

One repo for each project.


> I don't think putting it all into one giant repo isn't an option because that 
> would require all other projects (which are dozens) we have to be in it as 
> well. That would not only be an unmanageable mess, but we couldn't pull off 
> git migration for everything in one step anyway.
> 
> The other extreme would be separate repos for each app and each framework, 
> but wouldn't that mean that we couldn't do combined commits any more across 
> app and frameworks? Or is there another way to clarify for developers and 
> build servers which framework commit they need to pull to match a specific 
> app commit?

You could investiguate git submodule.
We plan on re-investigating it eventually, but last time we did, jgit didn't 
support it, so no eclipse support was a no go at the time.
If you go with submodule, you will have to make some decision about how the 
framework (the 'submodule') sources files are layout inside your 'app' projects 
and make it so that Eclipse is ok with it, potentialy having more than one 
project open at the same time (depending on your workspace layout).
I heard tools (gui tools) are getting more and more support for submodule, 
maybe it's finally ready.


> What would you do?

We have many repo, one per project (one per frameworks, one per applications, 
etc.), do not bother yet with submodule.  It worked well, this is what I would 
do once again.

ps: We see the dependencies management as a source-code problem (for frameworks 
that we control) as well as a deployement problem (for library / frameworks we 
have no control over).
We are actively evaluating maven to solve this problem.

--
jfv
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to