|
This is the perfect place for this question, so don't worry about it.
To answer your question, for custom builds for clients, we use source control to manage this. Basically, we have a branching strategy where these clients are branched off our main development trunk. Appropriate changes from the trunk can be merged down to those branches as appropriate. The process is a lot more involved than this, but that's the basic level (because we have branches off branches, to deal with test phases, etc, and release branches - it all sounds horrendously complicated, but our CI procedures make it a complete breeze).
|
|
|
|
|
I understand. It does indeed sound complicated but thinking enough about it, I can see how it really isn't so painful. Haha. Thank you all for the input! I use Git for source control, although I am a standalone developer, both independently at home and at work. I'm the only developer. But I've read about the many benefits of source control, even if you're a single developer. And I have seen truth to it all. Haha. But I'll look into branching more, I've seen the term in Git, just never took the time to learn. Thanks again!
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Depends on what the needs are.
Some possibilities exist with many variations within each.
- Create abstraction layers. Customer specific code replaces the default implementation.
- Run time meta data. The application functions differently based on data that drives the application. This can include but is not limited to run time scripting.
- Distinct application layers. A customer choice replaces a default layer.
- Customer overlays. Customer software is created which is part of a build step which either replaces source or binary sources with customer specific idioms.
- Extract customer choices and push them back into the main code base.
|
|
|
|
|
A custom build is necessarily a different BUILD, so things like run-time metadata is out the window. 
|
|
|
|
|
Source control is by far the easiest way to do this. It gives several benefits, to name a few:
Reverse Integration (fix a bug in one, move it everywhere)
Single point of backup (Developers don't have all the code on their machine)
Versioning
Simple version differencing
Many more. Once you start using something like TFS you'll never go back.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
Expert Coming wrote: Source control is by far the easiest way to do this
That doesn't seem to have anything to do with the OP.
The OP has a single product to which customizations must be done to support different customers. They are already aware of how to do that using completely different code bases (which is the only way in which source control can have an impact.) What they want is ideas on how to do that differently.
|
|
|
|
|
The last sentence in the OP is what I was replying to. He asked if this is usually done in SCC, to which my response was that it is the easiest way.
I did however fail to provide specifics which I should have done.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
I've been using jQuery quite a bit lately, and I've enjoyed how easily it makes navigating and manipulating the DOM.
When I think of other areas of my code, I sometimes wistfully wish it was as easily to mainpulate the data there as it is to manipulate the DOM with jQuery. This makes me wonder if I'm missing an abstraction. The DOM is really a tree at the heart of it. So maybe, where it makes sense, I could attempt to model the data in the domains I work in as trees. Then use a domain specific language to manipulate those trees.
|
|
|
|
|
Once one learns to use a hammer and practices with it quit a bit it is easy and fast to use it to join lumber in any number of different ways.
That doesn't mean it is a replacement for a drill.
And it certainly doesn't mean that one should use it when making a cake.
|
|
|
|
|
"Once one learns to use a hammer ... it certainly doesn't mean that one should use it when making a cake." 
/ravi
|
|
|
|
|
Hi,
we have a .Net based application (C#, VB) and we want to integrate basic document managment functions for the documents we create in our application.
We need to provide some functions for the users of our appication to manage the documents created within our documentation.
We don't want to have a stand alone DMS, we rather like to integrate a library/framework with basic structure and functions we can use in our code.
Like versioning, Check-In/Out mechanism.
I searched via google for quite a time but I have not found something. Maybe I don't use the best keywords.
I hope anyone knows a library on the market.
Thanks a lot! 
Edited: given more Informations and correct typing
modified 17-Sep-12 6:22am.
|
|
|
|
|
Try CVS[^] or SVN[^].
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks for your suggestion.
I think you missunderstood my question, so I edited my question to make it more clear.
We do not need to manage our own source code, we use mercurial for it.
I am searching for a DLL with we include in our c#/vb project. We need to link the managed documents to data in the customerdatabase.
We need to have meta-data /attributes stored with the document and a right managment within, also searching mechanism.
|
|
|
|
|
You're looking for an awfull lot of functionality, I doubt that you can simply add a reference and be done with it.
Your best bet would be to Google for an "open source DMS", and to modify it to suit your requirements.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Not sure why it needs to be open source and modified, as far as I read the requirements are pretty basic. Versioning and check-in/out appears to be all that's needed.
But I do agree that a DMS is probably the way to go and don't quite understand why the OP has decided a priori that they don't want that. After all, document management is the functionality they need...??
|
|
|
|
|
dojohansen wrote: After all, document management is the functionality they need...??
It sounds like it does, but without a response, we'll never know
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
NH71 wrote: We do not need to manage our own source code, we use mercurial for it.
That however doesn't alter the other suggestion of using a source control system. The source control system provides checkin/out of ANY file based product.
|
|
|
|
|
NH71 wrote: We don't want to have a stand alone DMS, we rather like to integrate a
library/framework with basic structure and functions we can use in our code.
Like versioning, Check-In/Out mechanism.
Based on this and your other posts this isn't going to be easy.
So far you have asked for
- Check in /out
- Versioning
- Rights management
- Document attributes, presumably associated with a user.
That would all need to come from somewhere. And it would need to be stored some where.
As per the other request a source control system would handle the first two requirements. But you would need to handle the second two yourself. And I expect that you have other unstated requirements as well.
Overall it suggests that you do in fact want a DMS.
|
|
|
|
|
I still relatively new to most things but in particular very new to design patterns and I'm struggling to pick a good pattern for a particular task.
I've chosen to do the Mandelbrot 'rite of passage' by trying to build a 'pluggable' class structure so that I learn more from this exercise than perhaps I otherwise would.
What I have right now looks like (I think) the strategy pattern with the builder pattern (I think) hidden in the constructors. I.e. I have an Imager class that has two members, both of which are of an Interface type. One interface is for the fractal set (mandelbrot, julia etc.) and provides a pluggable iteration / algorithm. The second is for a colouriser which provides a way to turn the results of the iteration into a colour. The set has a member that is an interface type, it is for the specific F(Zn) calculation in Zn+1 = F(Zn) + c. The colouriser also has one member that is an Interface type, it is for mapping the output of the colouriser to a specific colour. I think that is the strategy pattern? But I'm not certain (a) if it is, (b) if I've implemented it correctly or (c) if there's a better choice.
The Imager constructor can take a new set and a new colouriser, The set xcan take a new function and the colouriser can take a new mapper. I think that's builder?
Any help or guidance on a good choice for the job I described above would be very welcome as indeed would any help deciphering what I've already done!
Happy to provide code etc. as required to make sense of the mangled gibberish above.
Thanks,
Mike
|
|
|
|
|
Looks like your Imager class is general purpose enough and you've used IOC to provide the the smarts. Seems logical to me.
/ravi
|
|
|
|
|
I am beginning a basic shop floor control system for a client who currently consults giving advice on optimizing manufacturing processes. My problem is that he uses very broad and vague terminology in descriinbign requirements to me, and I would like, ideally, to consult some reference models or diagrams or such systems, but Google research is proving quite slow and not to fruitful.
For example, my client uses the term 'machine' for what I have found out could rather be called a 'work center', and has no term for what I have found out should be called a 'work center'. Adding additional tables required for a nice system design but don't feature in his paper design adds more challenge. What do I call the definition of 'the process done by a work center to produce a product (or BOM item)' etc.
|
|
|
|
|
There's no guarantee that the client is using accepted terminology. What you might want to do is to include a definitions section in your documentation that ties the terminology down; we've done this in the past and it's surprising how well it works when the client uses 6 or 7 terms to describe exactly the same thing.
|
|
|
|
|
Pete O'Hanlon wrote: There's no guarantee that the client is using accepted terminology.
Never mind a guarantee; there's hardly even a vague suggestion that he is using accepted terminology. I'm trying to find a nice taxonomy I can use for candidate terms we can agree on and move forward with.
I found Openbravo[^], an open source ERP system, which is very promising. Will look at it tonight.
|
|
|
|
|
I believe Oracle ERP documentation is available online. Try Googling for that.
|
|
|
|
|
Oracle documentation can be found here[^], (EBS, MRP, basically the whole line of their products) and I've been banging my head on the desk for the last 3 days trying to find any documentation even remotely useful.
I'm working on a highly-customised E-Business Suite (so maybe lack of documentation shouldn't come as a surprise), and I need to call some APIs to automate some tasks (No, I don't need help, yet )
All I'm saying is, Oracle documentation is     , but it might prove useful for your MRP research terminology
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
