> And I'm not aware of a good use of VSS sharing in the first place.[1]
I suppose we need to experiment with putting each file (or group of
related files) in it's own directory to see how thet works with
externals. Sounds a bit horrible...
One of the good things about sharing files is the ability for projects
to gain from debugging that goes on in other non-related projects - yes,
new bugs can get introduced and there is a chance that they "creep"
across all projects that use the shared file. But in our experience
this is extremely rare. Shared files tend to grow with additional
related methods, that growth is organic and slow, so we end up with
modules in our projects that provide stable and well tested libraries.
An engineer here starts a new project by firstly going to VSS and drags
together all the files they intend to use as a framework. It does mean
that you get some bloat, but it's worth the cost.
If the engineer wants to know where a files is used, they right mouse
click and view the projects it's shared in. Of course each file is
versioned and can be pinned to a particular version by label in each
project it's used in. So repeatable releases are easily achieved.
Listen, I'm not here to defend VSS, but equally I wouldn't want people
to think that everyting VSS is evil. Maybe the shared files is perhaps
the only thing that isn't?
Steve
-----Original Message-----
From:
users-return-58399-sohara=pivotal-solutions.co.uk@subversion.tigris.org
[mailto:users-return-58399-sohara=pivotal-solutions.co.uk@subversion.tig
ris.org] On Behalf Of Nathan Kidd
Sent: 15 November 2006 22:53
To: users@subversion.tigris.org
Subject: Re: VSS File Sharing
Thomas Wicklund wrote:
> I'm not aware of a good SVN replacement for VSS shared files.
And I'm not aware of a good use of VSS sharing in the first place.[1]
Well, I say that somewhat tongue-in-cheek -- certainly people can use it
to conveniently share files. But frankly from a SCM perspective, and
having gone through the whole "what do we do with these shared files"
problem when we converted from VSS to SVN, I posit that in software
development the concept of checking in a file in one location and other
locations silently getting changed too is a Bad Thing. I further posit
that every shared file is a kludge that should be fixed with a
project-independent lib, or similar concept. You can still get the
benefit of shared code without the inherent surprise/fragility VSS
sharing adds to a project development/SCM.[2]
-Nathan
_____________________________________
[1] Please note I'm speaking in the context of robust software
development where stable branches, tags/labels, are integral. Some
other type of short-lived content may not have the same drawbacks.
[2] "What surprise/fragility? I've been using it for years without
problem!" Maybe you have. Maybe your developers never introduce bugs in
new code. Maybe they always can remember which projects are using a
shared file. Maybe you don't maintain many old-but-stable branches. But
if you're concerned with stable, reproducable builds there are too many
maybes in there.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 00:29:12 2006