Search Results

Search found 1 results on 1 pages for 'selsine'.

Page 1/1 | 1 

  • Sharing the same file between different projects

    - by selsine
    Hi Everyone, For version control we currently use Visual Source Safe and are thinking of migrating to another version control system (SVN, Mercurial, Git). Currently we use Visual Source Safe's "Shared" file feature quite heavily. This allows us to share code between design and runtimes of a single product, and between multiple products as well. For example: **Product One** - Design Login.cpp Login.h Helper.cpp Helper.h - Runtime Login.cpp Login.h Helper.cpp Helper.h **Product Two** - Design Login.cpp Login.h - Launcher Login.cpp Login.h - Runtime Login.cpp Login.h In this example Login.cpp and Login.h contain common code that all of our projects need, Helper.cpp and Helper.h is only used in Product One. In Visual Source Safe they are shared between the specific projects, which means that whenever the files are updated in one project they are updated in any project they are shared with. This is a simple example but hopefully it explains why we use the shared feature: to reduce the amount of duplicated code and ensure that when a bug is fixed all projects automatically have access to the new fixed code. After researching alternatives to Visual Source Safe it seems that most version control systems do not have the idea of shared files, instead they seem to use the idea of sub repositories. (http://mercurial.selenic.com/wiki/subrepos http://svnbook.red-bean.com/en/1.0/ch07s03.html) My question (after all of that) is about what the best practices for achieving this are using other version control systems? Should we restructure our projects so that two copies of the files do not exist and an include directory is used instead? e.g. Product One Design Login.cpp Login.h Runtime Login.cpp Login.h Common Helper.cpp Helper.h This still leaves what to do with Login.cpp and Logon.h Should the shared files be moved to their own repository and then compiled into a lib or dll? This would make bug fixing more time consuming as the lib projects would have to be edited and then rebuilt. Should we use externals or sub repositories? Should we combine our projects (i.e. runtime, design, and launcher) into one large project? Any help would be appreciated. We have the feeling that our project design has evolved based on the tools that we used and now that we are thinking of switching tools it's difficult for us to see how we can best modify our practices. Or maybe we are the only people are there doing this...? Also, we use Visual Studio for all of our stuff. Thanks.

    Read the article

1