Hi Fred, I think there are many of us with experiences from old setups where SCM was just used wrong :)
Although your idea sounds possible, I'm not sure if it would be good for an enterprise setup. It kind of sounds like an internal open-source project, where the project leader accepts patches coming in from a big bunch of contributors. I don't think this would work internally in a company. I think you have several problems here, and I'm not sure if it's good to solve them by going to Git: 1. The workspace of a developer is too big. Working on 50 modules is too much. 2. The modules are highly coupled, changing one module often includes changing another, hence the need to keep them all in one workspace. 3. It's not practical to finalize and "release" a module - replacing the workspace module with a binary (JAR-file, DLL, whatever). You need to figure out which modules are applications, and which are libraries used by which applications. Then start treat them as individual projects. Where this doesn't work, you might have to merge together modules to single projects. These are general architectural issues that you'll have to deal with. Switching SCM might make things work a bit smoother, but won't fix the above. Depending on your colleagues knowledge of Git, switching might even make it worse, without proper training, etc. It always depends on context: But I would rather settle for an approach where I tried pulling out one library of the workspace (replacing it with a binary build), and then putting it in a Git repository for starters. This would serve as a nice trial of how to extract modules, and use Git at the same time. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
