On Thu, Dec 2, 2010 at 5:30 AM, Scott Yan <scott...@live.com> wrote:
> Below is our situation:
> There are a dozen sub-factories in our company , and we develop our ERP
> system ourselves, because there are very much diffrences between factories,
> our project became a dozen versions, which means we have a dozen repositoies
> for all the projects.
One of the biggest complaints I have with VSS (besides its ability to
render your entire source repository an unreadable mush of bits at
random times) was the "shared" files concept. As a CM, this is a
disastrous idea because it makes it almost impossible to understand a
project and its dependencies. You end up with a spiderweb of
dependencies that are almost impossible to trace. Not only that, but
the way VSS "shared" those files makes it impossible to say that a
particular file belongs to this or that project.
Imagine if a shared file is changed in another project, and it causes
a bug in your project. Who's problem is it? Which project actually
owns that file? You can unshare that file, but you lose what were
suppose to be the benefits of the share in the first place.
Subversion's idea of sharing directory trees, but not individual files
goes a long way in clearing this up because it forces you to think of
your subcomponents as a single unit and not a mash of files you can
pick and choose from.
That means if I share subcomponent "B", I have to define exactly what
"B" does and doesn't do. If "B" is suppose to manipulate data
structures in my project, it has to do so in an independent way.
Project "B" doesn't know what my SQL tables look like, or where my
pointers point.
That helps isolate errors. If I find a bug in my program, and I trace
that to subcomponent "B", I can say whether the error is with in "B"
or within my own project because I can look at the definition of what
"B" is suppose to do and say whether it matches that definition. If
the bug is truly with subcomponent "B", I know that bug is possibly
affecting other projects too, and that fixing that bug in "B" might
fix it in other projects. If I need to tweak "B" to get it to work,
and that might break its use in other projects, we can branch
subcomponent "B", or simply say that the other projects depend upon an
earlier version of "B" than my project.
The best thing to do is to start separating out the tenuous web of
dependencies your projects have with each other, and to clarify
exactly what each subcomponent will do. It might take months to clean
everything up, but it has to be done.
I'm thinking of starting an organization based upon Alcoholics
Anonymous for former users of VSS. ("Hello, my name is David, and I
used Visual Source Safe.") The concept is similar: The use of
Alcohol/VSS has made a complete mess of your life/project, Because of
your use of Alcohol/VSS, you've lost great friends/ highly regarded
co-workers, and it will take years to recover and get your
life/project back on track.
There will be times when everything looks hopeless and you fall into a
deep abyss of depression and you think whether or not abandoning
Alcohol/VSS is worth it. But, you take it one day at a time. You turn
to a higher authority (God/ISO 9000) to guide you.
--
David Weintraub
qazw...@gmail.com
