AW: Advice on repository design for multiple projects using shared source

Petriconi, Felix Felix.Petriconi at mevis.de
Fri Jan 28 10:04:32 CST 2011


Bill,

I just came back from the OOP, a software engineering conference in Munich with great talks by Martin Fowler, Erich Gamma, Peter Hruschka, Tom DeMarko and other great women and guys where there talked about how not to develop in such a way software and I am really sorry for you to be in such a mess.

So I assume that currently you are able to build all needed components?
If so, burn 2 safe copies on CDs and put them into a fridge ;-) So there is always a way back.

Then I would put everything into a single repository in the current available file structure as one commit.

Now create a new root folder and try to isolate single components and put them into different sub folders. Common files I would try to put into something like a lib folder. Something like

Newroot-Module-ModuleA
              -ModuleB
              -ModuleC
       -Lib-CommonA
           -CommonB

Probably you have to adapt certain paths that the common files are found.

In general I would try to create a test environment so that you can prove in beforehand in some way that everything is still working correctly after a change. Perhaps this would result in very big effort. But I am sure that you can figure a way out that the system is working. Then I would perform one small step, commit the change to the repository and test that still everything is working. If yes, proceed to the next change. If not look into your recent changes and fix the problem. And try to go in such a way to clean up everything. Always do just small steps! At the end, there is probably no need to maintain the complete history and you could create from the then new structure a new repository which you can use as the new starting point for further development.

I hope this helps a bit. I am neither familiar with VB nor with COBOL. But I would try to do it this way. In my past I stepped over such code as well and a code beautifier helps enormous to get code more readable. There are several available in the net.

Best regards, Felix


Development Manager

MeVis BreastCare Solutions GmbH & Co. KG
A MeVis Medical Solutions company
Universitaetsallee 29
28359 Bremen
Germany
Phone: +49 (0)421 33074-(9)20
Fax:      +49 (0)421 33074-50

E-mail: felix.petriconi at mevis.de
Website: www.mevis.de

Trade Registry: Bremen HRA 25204 HB
VAT ID: DE262661277

Executive Board: 
Carl J.G. Evertsz, Ph.D., Robert Hannemann, Ph. D.
MeVis BreastCare Solutions Verwaltungs-GmbH


-----Ursprüngliche Nachricht-----
Von: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] Im Auftrag von wrmarvin
Gesendet: Freitag, 28. Januar 2011 16:35
An: mercurial at selenic.com
Betreff: Advice on repository design for multiple projects using shared source


I have been brought into a company that has multiple software packages and
multiple projects per package written in Visual Basic 6 (and cobol) (on
Windows) by a single programmer over the past 15 years.  He was an
accountant and a self-taught programmer.  The programming is a poorly
structured mess!  There was no source code management system used.  All the
code and vbp projects were kept in a single directory.  The cobol is in a
separate directory.  There are 86 VB6 projects.  Most are exe-projects, but
some are dll-projects.  In many of the projects, a shared source code module
(say Main1.bas) is used in each project.  Generally this Main1.bas has a
"Sub Main" that is set as the startup procedure for the project.  Main1.bas
also has many other common functions and subroutines.  Some of the projects
also share some of the forms (progress.frm).  Some projects are cobbled
together from shared source and forms from multiple other projects.  He did
no version control and over 15 years all projects are still version 1.0.0.

I am new to Mercurial/TortoiseHG and have spent about 2 weeks studying
documentation and searching through the mailing list to try and figure out
the best way to setup repositories/sub-repos or remote-repos to try and get
this monster under control.  I think I am to the point of almost total
confusion on how to handle this mess.

I would think that shared source code needs to be tracked separately from
the main project code, but changes to the shared code may not effect some of
the projects because that project does not use the routine that was changed
in the shared code.  The original programmer just kind of "knew" what would
effect what.  This original programmer sold the company and software to the
current owner and I have very limited contact with him.

Any help/suggestions on how to initialize a repository system to begin
source control of this evolved mess would be greatly appreciated.

Thanks,
Bill

-- 
View this message in context: http://mercurial.808500.n3.nabble.com/Advice-on-repository-design-for-multiple-projects-using-shared-source-tp2366922p2366922.html
Sent from the General mailing list archive at Nabble.com.
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial


More information about the Mercurial mailing list