0

So I'm creating my project using a git source control and using some libraries from another repositories. But I'm also developer of this libraries and I want edit/debug them in my project so I can add it to project not alike binary dll but alike another project.

I found this article : Multiple projects in a solution vs. multiple projects in source control

But I'm working on Windows and usually just using Tortoise Git. I guess that will be really hard to configure it such way.

There is another idea. Do not add solution file to version control and create some readme how another developers must construct project and it's dependents.

Maybe someone already met or even solved such trouble, I'm interesting to know any solutions and variants for it.

Thank you.

Community
  • 1
  • 1
cnd
  • 32,616
  • 62
  • 183
  • 313

2 Answers2

2

At a company I used to work for, we ended up putting the projects themselves into different repo's which made managing them easier as opposed to 1 solution. We then wrote a batch file to simply put all the pieces back together and compile it correctly (just compiling the component Projects). This may not work for everyone but it is just a suggestion.

The reason we did this was because opening the solution in VS was getting to be very memory intensive for the machines and was becoming a giant mess of files.

Also this can be used so that teams only work on their specified software and can really only talk to the other components. This is a great way to enforce 3-tier/n-tier architecture design since you separate the projects out and let teams/developers only worry about what they're working on (not really fool proof but it helps).

Jesus Ramos
  • 22,940
  • 10
  • 58
  • 88
  • It's a good point. It will help me when libraries will became stable and no need for debug anymore I can easy remove them from solution and add as binary but for the moment I want them in my solution but not in the same repository. – cnd Jul 29 '11 at 06:10
  • That becomes a little harder but it can still be managed (you can probably write a script that will update ALL components for the solution). That approach is OK as well as I can't really see too many issues except when major changes roll around. – Jesus Ramos Jul 29 '11 at 06:11
1

In our company we usually have a solution consist of several projects, mostly dozen or several dozens. Those are coming from different repos 'cause some of those are general purpose libs, frameworks etc. We, however, use SVN with VS AnkhSVN plugin so there are completely no issues with commiting changes to more than one repo.

My assumption for you is to check whether Git VS plugins could work with seeral repos in one solution. More info on Git VS plugins here: Using Git with Visual Studio

BTW, accroding to 'one or many repos' discussion - we create one repo for a project. So if there are several parts of the project and some of those existed before and will most probably keep being after - those should not be placed in the project repo. Should something great be born within the project and we do believe this will overlive it - we could always migrate repo subtree to an independent SVN repo.

Community
  • 1
  • 1
Vitaly
  • 813
  • 10
  • 17