Looking for advice in managing code in related applications (long)
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
Dan Neely wrote:
The third is related to the second. For security reasons if customer X can't have feature Y, then X's application cannot have methods to implement Y in the common library even if X's application doesn't have any way to call the method because if they were clever enough they could do reverse engineering write their own front end that sits on top of the common library.
This, is a large part of what plugins are intended for. If they don't get the plugin, they can't load it, so there can be no reverse engineering. The bad news here, is that your company is going to have to take the financial hit for changes to the codebase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
I have done this in the past by having the core code into a base project or projects and custom code in the customer central project. I then use the primary project to dynamically load the dll's for the customer centeric project so the main application is driven from the core code. If two clients request two identical features the core code gets moved to the core application and the customer centric portion gets placed into the customer centric project. This helps to prevent divergence of the code base. For each customer, you deploy the base code and the customer centric dll's. Everyone is happy and it works well, albeit it can be tough to debug at times.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
I see this ending badly... In my experience, simple is always better than complex. I vote for one skin-able app with options that can be turned on/off. I'd explain at length but that would be complex and simple is always... well, you understand. ;)
Can't be done. Between NDAs and non-technical people having a copy of the source to look for "forbidden" terms the customer specific stuff must be kept out of the shared material regardless of what pain it may cause elsewhere.
3x12=36 2x12=24 1x12=12 0x12=18
-
Ennis Ray Lynch, Jr. wrote:
albeit it can be tough to debug at times.
What sort of problems did you encounter doing it this way?
3x12=36 2x12=24 1x12=12 0x12=18
Sometimes the debugger does not like to step into a dynamically loaded assembly. Most of the time it works I just mention it so you know it may exist in certain configurations. Otherwise, I am very happy with the approach. Can also be used to offer tiered feature-sets without the risk of someone just "enabling" a feature.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Dan Neely wrote:
The third is related to the second. For security reasons if customer X can't have feature Y, then X's application cannot have methods to implement Y in the common library even if X's application doesn't have any way to call the method because if they were clever enough they could do reverse engineering write their own front end that sits on top of the common library.
This, is a large part of what plugins are intended for. If they don't get the plugin, they can't load it, so there can be no reverse engineering. The bad news here, is that your company is going to have to take the financial hit for changes to the codebase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
The bad news here, is that your company is going to have to take the financial hit for changes to the codebase.
The way our bean counting works the hit'd be primarily born by whomever was the first customer to get a version refactored this way; with other existing customers being hit if they wanted an update. My (uneducated) get feeling is though that if more elegant this would be significantly more expensive than my thoughts about sub-classing, and since the extra money that got spent on the redesign would mean less customer visible stuff for their money this could be a problem.
3x12=36 2x12=24 1x12=12 0x12=18
-
Can't be done. Between NDAs and non-technical people having a copy of the source to look for "forbidden" terms the customer specific stuff must be kept out of the shared material regardless of what pain it may cause elsewhere.
3x12=36 2x12=24 1x12=12 0x12=18
-
I see this ending badly... In my experience, simple is always better than complex. I vote for one skin-able app with options that can be turned on/off. I'd explain at length but that would be complex and simple is always... well, you understand. ;)
Every book on coding theory and design I've ever read always says to avoid complexity. However, I am finding more and more that reading coding theory is like watching Microsoft demo a new technology: the examples are chosen to look great, to work perfectly, and to bear little resemlance to the challenges you meet in the trenches. Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
I can't offer anything anyone else hasn't already said, but can I ask that you please post your solution? This is a good, chewy one.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I can't offer anything anyone else hasn't already said, but can I ask that you please post your solution? This is a good, chewy one.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Since 1991, I have used a data profiling/historian product from OSISoft. When the application was used on an OpenVMS system, each site was given a build specific to them, and, there was a 'build manager' responsible for adding the products each client licensed. When they moved to a Windows NT environment, all customers were given the base application, but subsequent pieces were licensed individually. So... my 'vision' would be: modularize as much as possible each 'version'/'client site' gets an include file that ONLY has their pieces included if the call is never included, it can't be reverse engineered to 'add'/'hack' this functionality I hope only the best for you. If possible, keep us informed. Tim
Tim Carmichael wrote:
OpenVMS
:thumbsup: My only experience with a proper version control system is OpenVMS' CMS... and after reading (most of) the Subversion manual I believe CMS is superior at this sort of thing. The company I worked for at that time looked into Visual Source Safe as a replacement and decided that it just didn't have the required features. The thing is (as far as I can tell anyway) is that there is a whole different way of dealing with source code that the lesser systems enforce. It comes down to the operating sytem -- OpenVMS just does file handling way better than desktop operating sytems. When I finally got around to starting to write my own version control system a year ago, I took CMS' approach.
-
Every book on coding theory and design I've ever read always says to avoid complexity. However, I am finding more and more that reading coding theory is like watching Microsoft demo a new technology: the examples are chosen to look great, to work perfectly, and to bear little resemlance to the challenges you meet in the trenches. Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Avoiding complexity is easy. As long as you only ever deliver hello world.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Every book on coding theory and design I've ever read always says to avoid complexity. However, I am finding more and more that reading coding theory is like watching Microsoft demo a new technology: the examples are chosen to look great, to work perfectly, and to bear little resemlance to the challenges you meet in the trenches. Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
Of course... maybe I was being too simplistic. But given a choice between moderately complex and very complex - all things being equal I'll pick moderately complex. As an example: We use mostly Siemens CNC controls on the machine tools we manufacture. We often use a large Siemens application called Step 7 for machine logic. It's a 45 minute install (with various add-on libraries) and consumes about 1 Gb of HD space. No big deal, right? Well, over time my install became unstable and Siemens tech support recommended a full uninstall of all Siemens software and e-mailed me the documentation on how to do it. Something along the lines of: Go to control panel "Add / Remove Programs" Uninstall "Step 7" Uninstall "Step 7 Library ABC" ... Uninstall "Step 7 Library XYZ" Run registry editor and delete HKLM\Software\Siemens Go to Program Files\Siemens and delete *.* Go to C:\WINDOWS\SYSTEM32 and delete S7*.* I did all this without any problem. Rebooted and then on a hunch re-ran the registry editor and searched for terms like Siemens, Step 7, S7, Sinamics, Sinumeric (All Siemens product and trade names). Over 7000 registry entries remained!!! Seriously! With over 7000 orphaned registry entries is it any doubt that the system was unstable? Complexity gone wild!
modified on Wednesday, July 28, 2010 6:52 PM
-
If I go with something different than my original idea I can post a brief update. *mutter* NDAs *mutter* *mutter* can't write about in detail needed for an article *mutter* *mutter* *mutter* *mutter*
3x12=36 2x12=24 1x12=12 0x12=18
I won't say nothin'. Promise.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Chris Maunder wrote:
Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
Of course... maybe I was being too simplistic. But given a choice between moderately complex and very complex - all things being equal I'll pick moderately complex. As an example: We use mostly Siemens CNC controls on the machine tools we manufacture. We often use a large Siemens application called Step 7 for machine logic. It's a 45 minute install (with various add-on libraries) and consumes about 1 Gb of HD space. No big deal, right? Well, over time my install became unstable and Siemens tech support recommended a full uninstall of all Siemens software and e-mailed me the documentation on how to do it. Something along the lines of: Go to control panel "Add / Remove Programs" Uninstall "Step 7" Uninstall "Step 7 Library ABC" ... Uninstall "Step 7 Library XYZ" Run registry editor and delete HKLM\Software\Siemens Go to Program Files\Siemens and delete *.* Go to C:\WINDOWS\SYSTEM32 and delete S7*.* I did all this without any problem. Rebooted and then on a hunch re-ran the registry editor and searched for terms like Siemens, Step 7, S7, Sinamics, Sinumeric (All Siemens product and trade names). Over 7000 registry entries remained!!! Seriously! With over 7000 orphaned registry entries is it any doubt that the system was unstable? Complexity gone wild!
modified on Wednesday, July 28, 2010 6:52 PM
Siemens just want you to feel they are thinking of you. Lots.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
First off -- can branching do what you need? Second -- when you deliver the source code, do you send a repository? Or a group of files? I'm only acquainted with two version control systems: I've used OpenVMS' CMS layered product and I've read up on Subversion because I was going to try it out before I got laid off from my last job. Having used CMS, I see that Subversion (and probably every other popular system out there) is hindered by a lack of the grouping and flexibility that CMS provides. The company that used CMS considered VSS, but the lack of grouping was a show stopper. Having said that, I have thought some more on this subject and I have come to the conclusion that basically what we were doing was a form of branching the hard way. Otherwise, we did no branching, we didn't need it. So... what am I talking about? Subversion et al seem to only group files in "directories" -- this is not how I was trained, we just put all the files in one directory and build it. Grouping files in directories makes no sense to me primarily because you can't put a file in multiple directories without making multiple copies, which would eliminate many of the benefits of using a version control system. CMS has groups and a file may be in multiple groups. CMS also has classes which are similar to groups, but contain particular versions of files (these were used extensively by the build process). In CMS you can also refer to multiple libraries (which may be the similar to repositories) at once. What we did (and I don't intend to claim any credit; it was in place when I got there) was have a library for common code and separate libraries for each client system. One client library had no knowledge of the others. And by using groups, we could control which subsystems were to be included in a particular client's product. During the build, only the requested versions of the specified files were fetched and built. Obviously, we couldn't send a repository, but we could have ZIPped up the files and sent them if we wanted to (we didn't). Since I left there I have only worked at places with essentially no version control system X| , but I have often thought about writing my own -- taking lessons from CMS. A year ago (2009-07-30, according to my comments) I finally got around to a starting to do it. What I have now has most of the features I intended to have -- except for the ability to query the repository for its contents :~ -- I'm stuck on deciding what I want. I've barely looked at th
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
The problem might be in your accounting and business model. Many companies have solved this by building an extensible core product and then having a separate consulting branch to do customizations. You get a balance of steady core licensing money that can scale out with a variable amount of customization for installation and upgrade. Customers own the output of consulting but only license the core. 100% consulting work doesn't scale. Even with outside consulting, the entire "ecosystem" can be more profitable for the company than trying to own the whole thing.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
The problem might be in your accounting and business model. Many companies have solved this by building an extensible core product and then having a separate consulting branch to do customizations. You get a balance of steady core licensing money that can scale out with a variable amount of customization for installation and upgrade. Customers own the output of consulting but only license the core. 100% consulting work doesn't scale. Even with outside consulting, the entire "ecosystem" can be more profitable for the company than trying to own the whole thing.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
Andy Brummer wrote:
The problem might be in your accounting and business model.
In some ways it does except that senior management would call it by design. We started as a university spinoff, and they're extremely adverse to doing anything that would threaten out being able to call ourselves an Applied R&D Company which can stay under the non-profit umbrella.
3x12=36 2x12=24 1x12=12 0x12=18
-
First off -- can branching do what you need? Second -- when you deliver the source code, do you send a repository? Or a group of files? I'm only acquainted with two version control systems: I've used OpenVMS' CMS layered product and I've read up on Subversion because I was going to try it out before I got laid off from my last job. Having used CMS, I see that Subversion (and probably every other popular system out there) is hindered by a lack of the grouping and flexibility that CMS provides. The company that used CMS considered VSS, but the lack of grouping was a show stopper. Having said that, I have thought some more on this subject and I have come to the conclusion that basically what we were doing was a form of branching the hard way. Otherwise, we did no branching, we didn't need it. So... what am I talking about? Subversion et al seem to only group files in "directories" -- this is not how I was trained, we just put all the files in one directory and build it. Grouping files in directories makes no sense to me primarily because you can't put a file in multiple directories without making multiple copies, which would eliminate many of the benefits of using a version control system. CMS has groups and a file may be in multiple groups. CMS also has classes which are similar to groups, but contain particular versions of files (these were used extensively by the build process). In CMS you can also refer to multiple libraries (which may be the similar to repositories) at once. What we did (and I don't intend to claim any credit; it was in place when I got there) was have a library for common code and separate libraries for each client system. One client library had no knowledge of the others. And by using groups, we could control which subsystems were to be included in a particular client's product. During the build, only the requested versions of the specified files were fetched and built. Obviously, we couldn't send a repository, but we could have ZIPped up the files and sent them if we wanted to (we didn't). Since I left there I have only worked at places with essentially no version control system X| , but I have often thought about writing my own -- taking lessons from CMS. A year ago (2009-07-30, according to my comments) I finally got around to a starting to do it. What I have now has most of the features I intended to have -- except for the ability to query the repository for its contents :~ -- I'm stuck on deciding what I want. I've barely looked at th
PIEBALDconsult wrote:
First off -- can branching do what you need?
Maybe but I doubt it. We'd need to be able to control access permissions to each customer branch independently. that seems esoteric enough that I kinda doubt it'd be a feature.
PIEBALDconsult wrote:
Second -- when you deliver the source code, do you send a repository? Or a group of files?
Group of files. Take the latest svn snapshot, delete all the bin/obj folder junk. Delete all the .svn folders. Plop onto CD. Stuff into box. Ship. Get filed in customers CM system and forgotten about.
PIEBALDconsult wrote:
Grouping files in directories makes no sense to me primarily because you can't put a file in multiple directories without making multiple copies, which would eliminate many of the benefits of using a version control system.
From what I've been told SVN does support symbolic links if the file system of the server supports it. Moot point in my case since our companies infrastructure is windows based whereever possible; and either NTFS junctions don't do what SVN needs or do it in a way that offends punguinland sufficiently that they're unwilling to implement it. The latter reason probably applies to not implementing 'fake' symbolic links in software even if the underlying FS doesn't support them. Rational ClearCase does support symbolic links; but in every other way sucks far worse than SVN as a developers tool.
PIEBALDconsult wrote:
I'll close by asking what features you would like in a version control system to help alleviate your problems?
The lack of symbolic links is a pita so I definitely want that. To put everything in a single repository (vs having to pull from two to build any single customers app) would need setting access permissions at a folder level. Otherwise I'm fairly happy with SVN's current feature set. The blame tool is something I'd look for if switching to a new repository. This would be more useful in a document management than code management but the server being able to create customizable per user views (as in show me Foo.CS version 20, branch NewStuff everywhere it exists, latest file version for everything else) and expose them on a network share type interface (but without actually creating 100 shares with 100 copies of every files if the
-
PIEBALDconsult wrote:
First off -- can branching do what you need?
Maybe but I doubt it. We'd need to be able to control access permissions to each customer branch independently. that seems esoteric enough that I kinda doubt it'd be a feature.
PIEBALDconsult wrote:
Second -- when you deliver the source code, do you send a repository? Or a group of files?
Group of files. Take the latest svn snapshot, delete all the bin/obj folder junk. Delete all the .svn folders. Plop onto CD. Stuff into box. Ship. Get filed in customers CM system and forgotten about.
PIEBALDconsult wrote:
Grouping files in directories makes no sense to me primarily because you can't put a file in multiple directories without making multiple copies, which would eliminate many of the benefits of using a version control system.
From what I've been told SVN does support symbolic links if the file system of the server supports it. Moot point in my case since our companies infrastructure is windows based whereever possible; and either NTFS junctions don't do what SVN needs or do it in a way that offends punguinland sufficiently that they're unwilling to implement it. The latter reason probably applies to not implementing 'fake' symbolic links in software even if the underlying FS doesn't support them. Rational ClearCase does support symbolic links; but in every other way sucks far worse than SVN as a developers tool.
PIEBALDconsult wrote:
I'll close by asking what features you would like in a version control system to help alleviate your problems?
The lack of symbolic links is a pita so I definitely want that. To put everything in a single repository (vs having to pull from two to build any single customers app) would need setting access permissions at a folder level. Otherwise I'm fairly happy with SVN's current feature set. The blame tool is something I'd look for if switching to a new repository. This would be more useful in a document management than code management but the server being able to create customizable per user views (as in show me Foo.CS version 20, branch NewStuff everywhere it exists, latest file version for everything else) and expose them on a network share type interface (but without actually creating 100 shares with 100 copies of every files if the
Dan Neely wrote:
The lack of symbolic links is a pita so I definitely want that.
I'm unlikely to do that because I prefer the "stick 'em all in one directory" (per client system) approach. The directory tree approach only causes this kind of "problem". It's really a matter of operating system limitations and having the software development process follow what the IDE wants rather than the other way around.
Dan Neely wrote:
The blame tool
I may have to re-read up on that.
Dan Neely wrote:
control access permissions to each customer
Oh, yeah, I forgot about that; I don't currently support controlling access to libraries (or any other content). That might be important. CMS supports that sort of thing, but I've never seen it used -- all developers had full access to everything.
-
If I go with something different than my original idea I can post a brief update. *mutter* NDAs *mutter* *mutter* can't write about in detail needed for an article *mutter* *mutter* *mutter* *mutter*
3x12=36 2x12=24 1x12=12 0x12=18
Regarding symbolic links could you not use the Subversion externals http://svnbook.red-bean.com/en/1.0/ch07s03.html[^] where you can ink 2 repositories together Eg Common code repository C and then A and B would share this reference. Also regarding not exposing certain api's from a common set just have another layer in between that can pick and choose which common apis are exposed to A or B clients. If you were using C sharp you could use the internal's access modifier and then the internals visible to property if you wanted more separation of libraries. David Ooops replied to wrong post was suppose to be on PIEBALDconsult link