Some quick thoughts. We've just made the move from VSS to Subversion (with TortoiseSVN). We've got rid of all our shared files. There were only a few, so we've put them in a common folder. I suppose an alternative if you've been making extensive use of shared files, would be to put them in a separate repository, and use an svn:externals property to pull the shared stuff from the separate repository into an appropriate folder in the working copy of each of your other repositories. Also, my understanding is that Subversion locks aren't actually locks as such. They're more an indication that another user is currently working on a file, but there's apparently nothing in Subversion which will actually prevent multiple developers from ignoring that lock if they wish, and modifying and committing changes to a file "locked" by somebody else. This is my understanding so far; we haven't got far enough into it to have experienced that in anger. HTH, Conor
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brennan I'm interested in hearing how people use their source control. We currently use Visual SourceSafe (VSS) which it turns out (after some comparison with other options) is quite nice in terms of core feature set. However is isn't a true database with atomic commits so there is that constant risk of database corruption if a network connection dies. We've been pretty luck so far but we have had one fairly minor scare. It also lacks strong support for branching and changeset type changes. So I can certainly see benefits in moving to a more powerful tool. The problem is that the alternatives all seem to be missing one or more VSS features. For example I don't like Subversion/CVS because their lack of explicit checkouts means you can't tell which developers are working on a particular file (unless you use Subversion locks but then only one developer can edit the file at once, unlike VSS's multiple checkouts). So the current favourite is probably Perforce. I know several companies on DUG (most notably Accredo) use and love Perforce. It looks great. Costs a bit but we can probably handle that. The one feature it appears to be missing is Shared Files. To explain, VSS allows you to share a file between multiple folders. We have maybe a dozen Delphi projects and most of our source files are used by more than one project. That's fine, we put each project into a different VSS folder and share the files to the projects which require them. Unfortunately this appears to be a VSS specific ability. So the questions: 1. Does anyone know how to reliably achieve similar shared file between folders functionality in Perforce? 2. Most development companies must have similar shared source files. How do you structure your projects and source files? (Note: I am talking about source files used by projects here, not files which are compiled into VCL packages) Some thoughts on question 2: One option is to just put all files into a single directory. No need to share now! However this means that projects could easily end up compiling in files you don't think they are (or should be) using because Delphi will always find the file. With our current separate folders scheme there is some control and you can be fairly sure whether a project is or is not using a source file. Another option would be to put the projects in one directory, the source files in one or more other directories, and then get the projects to reference each source file by relative path. This way each project will only be able to compile in files which are specifically referenced in the project file so you can easily check which files are being used. The downside of this (and the previous option too) is that each project is directly sharing the files with the others. So if you are making multiple changes in one project over the period of a week or so then it quite probable that none of your other projects will compile until you are finished because they will be trying to compile in your changed files. This is particularly frustrating if you need to make a small unrelated change to another project midway through the week. So... what's a developer to do!? Cheers, David.
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
