Michael Miller wrote:
> The problem is the way the development teams work. They check out from SourceSafe, make changes and check in when the change goes to production (maybe). If one developer has a file checked out that doesn't stop others from working on the same file, merging when necessary. They rely on good communications?
>
SVN will help with the merging, but it works even better with good
communication.
> Each developer has an empty workspace (2000+ folders) and checks out only the files their working on. They compile and if the program requires other files not in their workspace their retrieved them from the dev server, qa server or production depending on where it's 1st found.
>
Retrieving files from a production server seems very stupid to me. This
seems to imply that they have files out of the version control, hence
with no backup whatsoever for this particular version of a given file.
Would be much better to have all the files in SVN and then use whichever
is best suited at that time. I hope that those files are relatively
rare, and if that's the case, you can have them into the final directory
but with a suffix of some sort. Or, if there are many, just use branches
inside the repository, considering trunk to be the "production" line.
> Checking out the full Subversion repository 23,000+ files into each developer's working copy doesn't work well with their build process (which is an in-house written Client/Server VB program which no one wants to take ownership of since the developer left). No surprise, but they would have the same issue with a ClearCase View and I'm sure with many other source control systems.
>
No worries here, SVN can do sparse checkout. But then again, why not
rewrite that build process from scratch? I mean, if no one wants to dive
into it, it gives good indication that it might be buggy anyway.
Handling more than 23000 files should never make any build tool choke.
> The fear is compiling from an SVN working copy with a full copy of the source they won't pick up the latest copy of includes from dev or qa. This wouldn't be a problem if they keep their working copy up to date. Most of these developers are used to a mainframe environment, not a Windows environment, and don't grasp the concepts of a good source control system.
>
Then teach them. They are not stupid, they can be given good arguments,
basing those onto real life situation that they have already
encountered. There must be some horror stories inside this team that you
can build upon to show you how dangerous it is for them to have all
those files out of source control and not to get their latest revisions.
> For those of you who wanted to know more about the problem to be solved, you're probably sorry you asked. Thanks again for all your comments and suggestions.
>
I'm not sorry, this organization looks very much a few that I have
encountered in the past. And with good teaching, most, if not all
developers will understand that it's better for them to have a more
complete repository.
Cheers
Olivier
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2364111
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-22 11:17:33 CEST