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
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
-
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
Regarding symbolic links could you not use the Subversion externals <a href="http://svnbook.red-bean.com/en/1.0/ch07s03.html">http://svnbook.red-bean.com/en/1.0/ch07s03.html</a>[<a href="http://svnbook.red-bean.com/en/1.0/ch07s03.html" target="_blank" title="New Window">^</a>] 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
-
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
Taking a guess, that's probably COM object registration cruft. Cleaning it up properly usually requires intimate knowledge of the application. If Siemens is willing to provide a documented procedure for doing a complete 'cleanup' operation, they ought to simply automate it and clean the registry while they're at it. - from the Been There, Done That files
Software Zen:
delete this; -
I won't say nothin'. Promise.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Just a little note to 7,000,000 of your closest friends, right?
Software Zen:
delete this; -
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:
Group of files. Take the latest svn snapshot, delete all the bin/obj folder junk. Delete all the .svn folders.
TortoiseSVN :thumbsup:, so i assume that other clients probably have it too, has a function called Export that does all of that for you. Just in case you didn't know. Manually finding those .svn directories can be a pain in a large project.
-
Dan Neely wrote:
Group of files. Take the latest svn snapshot, delete all the bin/obj folder junk. Delete all the .svn folders.
TortoiseSVN :thumbsup:, so i assume that other clients probably have it too, has a function called Export that does all of that for you. Just in case you didn't know. Manually finding those .svn directories can be a pain in a large project.
Steven Nicholas wrote:
Just in case you didn't know.
I did not. Thanks.
Steven Nicholas wrote:
Manually finding those .svn directories can be a pain in a large project.
Doing a search for ".svn" in explorer let me cleanup in a minute or three on a fairly large sized project but delivery day is always a rush...
3x12=36 2x12=24 1x12=12 0x12=18
-
Macros might work in theory but one of our deliverables is source code to A1 (who in sells the system our app's part of to the other users); trying to explain that the IFDEF's mean that even though an item we can't give to the end user is in the source isn't in the executable is somewhere we don't even want to think about going. Even if we crossed that bridge new developers not having NDA access to what we did for old customers would be a show stopper. Include files are out because it's a C# app; not C/++.
3x12=36 2x12=24 1x12=12 0x12=18
.. o.k. I'll say this right off.. it's not elegant.. but: You could really Hack up your libraries, into a partial class definition for Each method, and build a class "library" then when you compile, you can use an internal reflection tool ( i recently saw something similar for projects, but while playing with it i noticed you can get fairly granular) to get just the methods you actually want to give that particular client, .. this method would be tedious but would have very little.. housekeeping while the code was in development.. Alternatively you could do MyClass_Common.cs,MyClass_AI.cs, myClass_A2.cs.. using the same MyClass namespace for each of the "MyClass_{blah}" files, this forces you to do housekeeping, and you will need every permutation of company sharing represented in your file base.... easy to do if you have one or two companies, but you get a much larger file base (and more complicated) if you take on a new client... (3 clients: 3!+1 = 7files, 4 clients: 4!+1 = 25, 5 clients: 5!+1 = 121)!... so not a very good choice if you want to keep getting new clients... :-D
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
-
.. o.k. I'll say this right off.. it's not elegant.. but: You could really Hack up your libraries, into a partial class definition for Each method, and build a class "library" then when you compile, you can use an internal reflection tool ( i recently saw something similar for projects, but while playing with it i noticed you can get fairly granular) to get just the methods you actually want to give that particular client, .. this method would be tedious but would have very little.. housekeeping while the code was in development.. Alternatively you could do MyClass_Common.cs,MyClass_AI.cs, myClass_A2.cs.. using the same MyClass namespace for each of the "MyClass_{blah}" files, this forces you to do housekeeping, and you will need every permutation of company sharing represented in your file base.... easy to do if you have one or two companies, but you get a much larger file base (and more complicated) if you take on a new client... (3 clients: 3!+1 = 7files, 4 clients: 4!+1 = 25, 5 clients: 5!+1 = 121)!... so not a very good choice if you want to keep getting new clients... :-D
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...