Are there any patterns out there to manage incremental change of a system. I have a drawing and I want to manage its changes. Rather than processing the whole thing from scratch every time, Id like to store the already processed stuff, and only introduce the delta for each subsequent change.
Anyone seen a pattern to deal with that?
> cvs? I don't understand. This is for somthing
> within my code, not about changes in my code itself.
> I need to processes changes in my drawings which are
> created within my software. Its a software code
> question not 'change management' so to speak.
it is change management, isn't it? CVS is a version control system, not just a source code control system. loads of people keep documents and other non-source code artifacts in a CVS repository. my last job, we did away with relational databases altogether and serialized everything to XML, then kept it in a subversion repository. worked a treat
Thanks for your suggestion. However, there is no way CVS is going to do what I am asking. Its like when you change a java file in Eclipse and Eclipse rebuilds just that one file as opposed to all files. You can't use CVS for that. That is what I want.
When someone modifies a drawing, I need to register the change, and update my error icons. I don't want to reprocess all figures in the drawing just because 1 figure changed. So I want to be able to take just the change delta and know if there are new errors.
are you talking about a team working on the drawing? presumably this is some vector graphics, where you can adequately describe a single change, yeh. I'd still be thinking about using CVS or SVN as a repository, and focusing on encapsulating individual changes in a serializable way. for instance, your app could describe each change in terms of XML, which is then committed to the repository. that's if I've understood the problem right. I'm not suggesting you keep the image itself in the repository as one atomic object, but the changes that describe the image
am I making sense?
>> When someone modifies a drawing, I need to
>> register the change, and update my error icons. I
>> don't want to reprocess all figures in the drawing
>> just because 1 figure changed. So I want to be
>> able to take just the change delta and know if
>> there are new errors.
If you saw this before the edit, I apologize. Even though you are not worried about undo (at least not in this question) I think the Memento pattern may be applicable to this. It focuses heavily on undo in the examples but it's really about externalizing incremental changes without breaking encapsulation.
No I was not concerned with undo dubwai. However, I have a full undo system with commands. So you pose an interesting point.
But its not needed to store the change. The change has happened. The drawing needs to be updated immediately. I can reparse the whole drawing, or I can have the state maintained in some way that it can accept just the 1 change and update the errors.
I know you can't design the system, but i was wondering if there were any common patterns used when someone has this type of desire. Eclipse building is a good example of an incremental change processing system. I have been modelling after that somewhat.
> No I was not concerned with undo dubwai. However, I
> have a full undo system with commands. So you pose
> an interesting point.
>
> But its not needed to store the change. The change
> has happened. The drawing needs to be updated
> immediately. I can reparse the whole drawing, or I
> can have the state maintained in some way that it can
> accept just the 1 change and update the errors.
>
> I know you can't design the system, but i was
> wondering if there were any common patterns used when
> someone has this type of desire. Eclipse building is
> a good example of an incremental change processing
> system. I have been modelling after that somewhat.
I don't know a pattern off hand. No. I would think that you'd need to know all the dependencies for the item that has been changed and then recursively determine whether that dependency is possibly affected by the change.
The reason I mentioned memento is because they have some discussion about capturing incremental changes. I'm looking at it now and it mentions the Command pattern in this section (Implementation, section 2.).
It seems to me that in order to avoid reparsing you will need to keep the entire parse tree in memory and recursively follow the dependencies of changed items. I doubt that's much help to you.
