We are using subversion and it has the same problem.
We re-arranged our project structure so that there is a folder that contains all of the common code which is well organised into sub folders. Each projects folder actually contains a minimal set of files that are currently, and always going to be, completely unique to that project. Sometimes this is just the main form. The rest of the files are under Common. The project uses clause contains a list of every file in the project with relative paths. Files for components are'nt listed in the project because they are in folders that are in our Library path. You mentioned that it may be a problem for all projects to share the same copy of a file, but I think it works better this way. In this case you can make the changes to your file, and then make sure it works with other project before checking things in. When the files were shared it was pretty common for someone to check is a change that worked with one project, but not with another. The only thing that this doesn't handle is files that are shared between each project that are not compiled into the exe, such as help files. In subversion you can share folders (using svn-externals), so we have a common folder that contains these files and share this folder with each project that needs them. Again this has actually improved things because these files are nicely organised into sub folders rather than all being in the same folder as the exe. Stacey From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brennan Sent: Wednesday, 26 September 2007 10:12 To: 'NZ Borland Developers Group - Delphi List' Subject: [DUG] Source Control - Sharing files between projects Hi, 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
