>* 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*.
Think of it this way:
I've a large library of routines I use on most of my projects. No problem if
it's an internal project; then I just carry around the whole library directory.
But for clients, I just pull in the routines I use; I don't want to hand them my
whole library. Since it's different files for different clients, I keep
copying things around. And sometimes I'll add to the library functions that a
particular project is using. Then I have to update all the other projects (base
library plus any other projects using affected modules). PITA...
I've *almost* gone to putting *every* library file in a subdirectory so I can
svn:externals them into each project - that's absurd though...
>* Ok - for some folks a missing GUI was the biggest issue. But most of
>that complaining went away after a few months. However, our editorial
>department is still on VSS and integration with Dreamweaver is the
>biggest thing holding us back. (Though to be fair I haven't pursued
>this vigorously.) None the less, better GUI and integration tools only
I was concerned about not having a GUI, but after using TortoiseSVN for a while,
I really like it.
My only real complaint is that when I import a project, I can never remember if
I need to import from the parent directory or the project directory...
- Al -
-- Alan Weiner -- alan_at_ajw.com -- http://www.ajw.com
Palm OS Certified Developer
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 18 02:23:51 2004