You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve O'Hara <so...@pivotal-solutions.co.uk> on 2006/11/15 19:28:30 UTC
VSS File Sharing
I'm a newbie to SVN and come from a VSS (I know, I know) background.
We'd really like to switch to subversion but the one show-stopper for us
is the lack of file sharing.
A very large number of our VSS projects share code files. In fact, I'm
not sure we have any projects that don't share some sort of file with
another project.
Now VSS has it's faults, but this feature is a real winner in our
developer community and prevents the re-invention of the wheel. In
fact, I'd go further and say thay this feature has been fundamental to
the increased stability of some of our modules - as they get used in
more and more projects they get better and better debugged in more and
more diverse operating conditions.
As I understand it, the "externals" feature of svn is only applicable to
directories. Has anyone got any ideas how I could mitigate the lack of
sharing files in svn that might come some way close to exhibiting the
desired behaviour?
Thanks,
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: VSS File Sharing
Posted by Talden <ta...@gmail.com>.
> 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.
Create the shared code as a bundle with its own release cycle.
Each project that uses it is currently using a specific version.
Projects advance to the next version when and if necessary... EG a new
release of the shared bundle is done (and tested) - it's benefits are
noted and ProjectX wants it immediately. ProjectY doesn't benefit so
they skip that change. They might well take the next one though.
These releases are entirely internal and are specifically to reduce
risk and to prevent projects developing against moving targets
unnecessarily.
None of this prevents the shared code model, and these bundles don't
have to be self-contained libraries, merely code structures stable at
a known point. Since they're always changed at the source merging
forward is trivial.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: VSS File Sharing
Posted by Tim Hill <dr...@comcast.net>.
+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
RE: Re: VSS File Sharing
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Wednesday, November 15, 2006 11:28 PM +0000 Steve O'Hara
<so...@pivotal-solutions.co.uk> wrote:
> 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.
The "fold it all into a bowl and stir" model of development. This should
introduce no more or less bloat than keeping the modules in a separate
library. But I can't see how it makes working with the modules easier.
I'm introducing a new vendor library into some old code moved from VSS to
SVN. That library is going into its own directory, not getting dumped into
the project directory as has been done by other developers in the past.
It's a separate subsystem, and it should be organized that way.
Dumping all your modules into one directory is like dumping all your source
into one big text file. Those with primitive single-file editors may like
the latter, but I find huge source files clumsy, and I find huge
directories full of unrelated modules equally clumsy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: VSS File Sharing
Posted by Steve O'Hara <so...@pivotal-solutions.co.uk>.
> 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
Re: VSS File Sharing
Posted by Nathan Kidd <na...@spicycrypto.ca>.
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
Re: VSS File Sharing
Posted by Thomas Wicklund <wi...@eskimo.com>.
Externals don't really match VSS file sharing since they have to be
checked out, committed and updated separately (if I understand them
correctly). My organization went from VSS to SVN. We used VSS shared
files for common code between products. Luckily in our case there
were so few non-shared files (<1%) that we just converted to a single
code base and conditional compilation, removing the need for shared
files.
I'm not aware of a good SVN replacement for VSS shared files.
Thomas Wicklund
Tim Hill writes:
> Yes, externals would do it. Since you are at a "cusp" if you switch
> scc systems, I also would advocate cleaning up the way you share
> files -- you are much better off sharing at the folder level than
> individual files here-and-there all over the place. Much more robust.
>
> --Tim
>
> On Nov 15, 2006, at 11:28 AM, Steve O'Hara wrote:
>
> > I'm a newbie to SVN and come from a VSS (I know, I know) background.
> > We'd really like to switch to subversion but the one show-stopper
> > for us
> > is the lack of file sharing.
> > A very large number of our VSS projects share code files. In fact,
> > I'm
> > not sure we have any projects that don't share some sort of file with
> > another project.
> >
> > Now VSS has it's faults, but this feature is a real winner in our
> > developer community and prevents the re-invention of the wheel. In
> > fact, I'd go further and say thay this feature has been fundamental to
> > the increased stability of some of our modules - as they get used in
> > more and more projects they get better and better debugged in more and
> > more diverse operating conditions.
> >
> > As I understand it, the "externals" feature of svn is only
> > applicable to
> > directories. Has anyone got any ideas how I could mitigate the
> > lack of
> > sharing files in svn that might come some way close to exhibiting the
> > desired behaviour?
> >
> > Thanks,
> >
> > Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: VSS File Sharing
Posted by Tim Hill <dr...@comcast.net>.
Yes, externals would do it. Since you are at a "cusp" if you switch
scc systems, I also would advocate cleaning up the way you share
files -- you are much better off sharing at the folder level than
individual files here-and-there all over the place. Much more robust.
--Tim
On Nov 15, 2006, at 11:28 AM, Steve O'Hara wrote:
> I'm a newbie to SVN and come from a VSS (I know, I know) background.
> We'd really like to switch to subversion but the one show-stopper
> for us
> is the lack of file sharing.
> A very large number of our VSS projects share code files. In fact,
> I'm
> not sure we have any projects that don't share some sort of file with
> another project.
>
> Now VSS has it's faults, but this feature is a real winner in our
> developer community and prevents the re-invention of the wheel. In
> fact, I'd go further and say thay this feature has been fundamental to
> the increased stability of some of our modules - as they get used in
> more and more projects they get better and better debugged in more and
> more diverse operating conditions.
>
> As I understand it, the "externals" feature of svn is only
> applicable to
> directories. Has anyone got any ideas how I could mitigate the
> lack of
> sharing files in svn that might come some way close to exhibiting the
> desired behaviour?
>
> Thanks,
>
> Steve
>
> ---------------------------------------------------------------------
> 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
Re: VSS File Sharing
Posted by Justin Patrin <pa...@gmail.com>.
On 11/15/06, Steve O'Hara <so...@pivotal-solutions.co.uk> wrote:
> I'm a newbie to SVN and come from a VSS (I know, I know) background.
> We'd really like to switch to subversion but the one show-stopper for us
> is the lack of file sharing.
> A very large number of our VSS projects share code files. In fact, I'm
> not sure we have any projects that don't share some sort of file with
> another project.
>
> Now VSS has it's faults, but this feature is a real winner in our
> developer community and prevents the re-invention of the wheel. In
> fact, I'd go further and say thay this feature has been fundamental to
> the increased stability of some of our modules - as they get used in
> more and more projects they get better and better debugged in more and
> more diverse operating conditions.
>
> As I understand it, the "externals" feature of svn is only applicable to
> directories. Has anyone got any ideas how I could mitigate the lack of
> sharing files in svn that might come some way close to exhibiting the
> desired behaviour?
>
I would suggest putting each of your reused modules in its own
directory so that it can be checked out by "externals".
--
Justin Patrin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org