Jean-François Veillette, Wed, Aug 29, 2007 20:18:14 +0200: > The company currently use cvs, it has a cvs tree where the first > directory level is per client, the second directory level is the > project, then inside it we have the many artifacts, like : > cvsserver/Shared/Documentation/PresentationTemplate.doc > cvsserver/Shared/Documentation/AnalysisTemplate.doc > cvsserver/Shared/Devel/CommonLib/* > cvsserver/ClientA/ProjectA/Doc/Presentation.doc > cvsserver/ClientA/ProjectA/Doc/Analysis.doc > cvsserver/ClientA/ProjectA/Dev/ApplicationA/* > cvsserver/ClientA/ProjectA/Dev/ApplicationB/* > cvsserver/ClientA/ProjectA/Dev/ApplicationC/* > cvsserver/ClientA/ProjectA/Dev/LibraryA/* > cvsserver/ClientA/ProjectA/Dev/LibraryB/* > > What would be the best way to represent a similar setup in git ? > I was thinking of having a repository at the project level, and add > atomic subdirectories (code for applications and libraries for > example) as submodules. > If submodule are the right way to go, ... not necessarily. I'd try plain branches first, unless the client's projects have lots of applications (or libraries, IOW, modules) and many of them are optional for your development process. "Optional" better fits what submodules are: their presence is supermodule is optional too. Many fixes after introduction of the submodules was just ignoring them :) > ... can a submodule, include a submodule, for example, > ApplicationA use LibraryA and CommonLib ? yes. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
