+1 -- I concur, it's a bad thing.
I think what it boils down to is you can setup the needed structure
in the WC and repo, but actually getting the files shared between
projects will involve a *explicit* step (probably a merge), rather
than have VSS do it magically. imho, making this explicit is good,
even if it involves some extra work.
And yes, you will forget to merge the first few times...
--Tim
On Nov 15, 2006, at 2:52 PM, Nathan Kidd wrote:
> 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:25:40 2006