How to share code between projects w/ versioning?
Author
OK, let me tell you what I'd like to achieve.
I have a lot of common source code between a few projects, your average "basecode" sort of deal. It has become quite large, and I now have a few projects using it, so manual management has become tedious.
Basically, the problem is - say project A and project B are using the same code base. I work on B for a while and while I'm doing that I update the basecode a bit. Now if I go to project A, the basecode has changed, and now A won't compile without being updated to use the latest basecode. Now, updating A is the best solution, but it's somewhat impractical, particularly if A becomes very outdated and I need to make a small, quick change to A.
What I'd basically like to do is be able to use the old base code for A while still using the new basecode for B. Then when (and if), I'm ready to update A to use latest basecode, I can just click a button to bring the version in use forward.
Even better would be if I could modify some basecode from A and some other basecode from B and then later merge the two modifications to the basecode when I want either A or B to move to the latest basecode version.
I'm under the impression that "CVS" is the correct answer to this problem, however I havn't used one before and so I don't actually know if it is. So, if it is, any advice on what software to use and how to use it to solve this problem is very much appreciated.
Ease of use would be a big plus (something that can just slot into MSVC is very preferable).
So yeah, any ideas?
EDIT: more info down the page.
[Edited by - Andrew Russell on June 1, 2005 8:13:25 AM]
Hi,
I think VCS can be easily integrated with VC++. Not sure of CVS. But yes, I would suggest CVS or some kind of versioning system.
I think VCS can be easily integrated with VC++. Not sure of CVS. But yes, I would suggest CVS or some kind of versioning system.
I think Visual SourceSafe is what you're looking for. It'll plug into Visual Studio.
Because I use Linux only, I have a lot of experience with using CVS, and while I only use it from the command-line I'm pretty sure there are a lot of user interfaces to make it easier.
Another thing- Why can't you just make the code that's common to both of them a library so that you don't need to keep them synchronized, just link it to the library. That's what I would do.
Because I use Linux only, I have a lot of experience with using CVS, and while I only use it from the command-line I'm pretty sure there are a lot of user interfaces to make it easier.
Another thing- Why can't you just make the code that's common to both of them a library so that you don't need to keep them synchronized, just link it to the library. That's what I would do.
I'd recommend Subversion.
Basically, it sounds like you'd want to take your base code, make a branch for A and a branch for B. At this point, they use common base code, but any changes made to the base code in A or in B will not change the other branch.
When you are ready to update A's basecode (assuming B's basecode as been modified), you can merge the B's updated basecode into A's basecode.
All of this shouldn't be too hard, but I do recommend you read the subversion book (it's free, listed on the website above).
Edit: And there is a visual studio plug-in available too: Ankh SVN
Basically, it sounds like you'd want to take your base code, make a branch for A and a branch for B. At this point, they use common base code, but any changes made to the base code in A or in B will not change the other branch.
When you are ready to update A's basecode (assuming B's basecode as been modified), you can merge the B's updated basecode into A's basecode.
All of this shouldn't be too hard, but I do recommend you read the subversion book (it's free, listed on the website above).
Edit: And there is a visual studio plug-in available too: Ankh SVN
I use symbolic links, which could probably be considered a hack.
I don't think that would work in Windows, though.
I don't think that would work in Windows, though.
Quote:Original post by smart_idiot
I use symbolic links, which could probably be considered a hack.
I don't think that would work in Windows, though.
This is similar to what I was suggesting. Just add to your path the directory that would have the stuff that's used between the projects and just include it and link to the library as normal. Cleaner and quite cross-platform.
Author
I think I need to better explain what I'm doing and how I'm doing it. The basecode is a seperate collection of source code. For example, my directory structure looks like this:
Originally, each project had its own copy of the basecode. This caused two problems: Firstly, bugs that got fixed in one copy were not fixed in another copy causing all kinds of problems, and features that got added to one copy were very difficult to move to another. The second problem was that it took a long time (hour or more) to pull together the code and create a new project (it now takes about 5 minutes - I am aiming for 0 minutes (automation) eventually).
@Mercury: There are several problems with making the basecode a library. The interface may change for starters. It also uses a lot of templates, which can't be DLL'ed. Also, there are a lot of optional modules that would bloat the library.
Anyway, Subversion/AnkhSVN seems to be the solution that I'm after. However, I'm still interested to know the best way of achieving the desired result.
Hallucinogenic's solution seems workable. However, I'm not really keen on having a seperate branch for each project - I am concerned this could cause the same problems as when each project had its own copy of the basecode. The ability to use a rolled-back version for a project until the project is ready to be updated, or the old version of the basecode is modified and thus split (to possibly later be merged), seems preferable.
Anyone have any oppinions or other options on this? Or advice for implementing it?
Anyway - more input is appreciated. I'll keep researching it and look into Subversion.
/basecode//projectA//projectB/etc...Originally, each project had its own copy of the basecode. This caused two problems: Firstly, bugs that got fixed in one copy were not fixed in another copy causing all kinds of problems, and features that got added to one copy were very difficult to move to another. The second problem was that it took a long time (hour or more) to pull together the code and create a new project (it now takes about 5 minutes - I am aiming for 0 minutes (automation) eventually).
@Mercury: There are several problems with making the basecode a library. The interface may change for starters. It also uses a lot of templates, which can't be DLL'ed. Also, there are a lot of optional modules that would bloat the library.
Anyway, Subversion/AnkhSVN seems to be the solution that I'm after. However, I'm still interested to know the best way of achieving the desired result.
Hallucinogenic's solution seems workable. However, I'm not really keen on having a seperate branch for each project - I am concerned this could cause the same problems as when each project had its own copy of the basecode. The ability to use a rolled-back version for a project until the project is ready to be updated, or the old version of the basecode is modified and thus split (to possibly later be merged), seems preferable.
Anyone have any oppinions or other options on this? Or advice for implementing it?
Anyway - more input is appreciated. I'll keep researching it and look into Subversion.
On the topic of source control, I use Perforce at work, and really like it. You can download and use a 2-client version for yourself for free. If you need more users, you need to buy licenses. It also has decent vs.net integration.
Your goal seem to be to end up with one source base that both project A and project B is using.
I would try to keep A and B syncrhonized with the base code even if that would require some extra time. I would also try to not switch too much between projects, like having project A and base as your main project and only update B when it's absolutly necessary. This solution would of course require that you don't change the base code too much and too often.
If you want to use separete code bases for the projects however, you might be easier off just having two separate source bases and doing a manual resynch once in a while. But then you won't get the bugs that you fix in one common base though.
The only thing left would be using a versioning system.
I would try to keep A and B syncrhonized with the base code even if that would require some extra time. I would also try to not switch too much between projects, like having project A and base as your main project and only update B when it's absolutly necessary. This solution would of course require that you don't change the base code too much and too often.
If you want to use separete code bases for the projects however, you might be easier off just having two separate source bases and doing a manual resynch once in a while. But then you won't get the bugs that you fix in one common base though.
The only thing left would be using a versioning system.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
