> >* Support for shared files. That is the same file being located in
> >more than one location in the repository. If you edit/commit in one
> >location it is updated in the others. This was the most
> painful loss
> >in functionality we experienced when switching to Subversion.
>
>
> This is a constant irritation for me.
>
> It's not enough to stop *me* from using Subversion, but I
> know several companies
> who rejected it *immediately* for just that reason. They
> all have common
> *files*; not common *directories*.
I used to use this feature in SourceSafe and then discovered that I really
didn't like it. To me it's like multiple inheritence, it sounds good but I
really think the world is better off without it *ducking*. I was bitten
more often by checking in a change to a shared file but forgetting to do a
get latest in all the other projects that shared the file, making for a lot
of head scratching until we remembered there was a shared file. The other
way I was bitten is when a source file in one project was commited by a
junior programmer or a contracter that really had no idea that the file they
had just "optimized" was actually shared by 10 different projects.
Forcing everything into libraries that are clearly labeled as such prevents
most of this and I find subdirectories useful for the cases when I only want
a subsection of my library exposed. I found it easier to manage by spliting
out certain routines into more than one source file or putting multiple
common library files into different library folders. Something along the
lines of
\publiclib
\privatelib
\common <- used by both public and private
Two cents from a Delphi Windows developer, running svnserve/svnserver on
XPSP2.
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 18 20:31:05 2004