Here's a suggestion which may give you a good compromise:
The first thing you need to arrange is to make sure that you totally separate
all your logic from your form code. So let's say you have an OnButton1Click()
event handler, then you just delegate this straight down to another class that
knows nothing about the GUI. In this way, you minimise the amount of code
affected by the next step.
So, you have your main trunk, and you create the bugfixing branch. You now have
two versions of the form, which can't be merged. OK, there doesn't seem to be a
better solution, so we'll just have to accept that for the actual forms
themselves, you'll need to add any bugfixes to both branches manually. However,
due to what we did before, this should be a minimal amount of work, as I guess
the form itself shouldn't change too much just for bugfixes.
Any logic changes are totally separate from the forms now, and can be merged
with SVN in the usual way.
I have a similar setup with Borland C++ Builder, and although I haven't actually
tried this on any branches, I guess it should work OK. It really depends how
much your actual GUI changes for the bugfixes.
BTW - your delegate class should know nothing about the form: I have a sort of
triangle of classes created from the classic 'dependency inversion':
Form1 - inherits and implements interface Form1View, also creates a
Form1Presenter which is the delegate class, and passes itself to the presenter
as a Form1View class.
Form1View - provides simple access methods for setting stuff on the GUI, which
are all pure virtual, and none of which have any GUI knowledge in, e.g. just
SetProgressValue(int val) or something like that.
Form1Presenter - implements the actual logic behind the events it gets from
Form1, and updates the form via the view class.
I don't know VB so I don't know if you could do the same, but I hope that helps
somewhat,
Robin.
BTW - you'd be better off over on the Subversion list with this, it's not really
a Tortoise question.
John Browne wrote:
> Depending on what controls you have on the form, they are necessary.
> Not every form will require them. However, some forms will have
> controls that save their "settings" in these frx files. The control
> will have an offset value for it's settings in the frm file. This
> tells VB where to look for that control's settings in the frx file.
> It seems to me that MS could have done the same thing with a
> text-based file (ini, xml, etc), encoding anything that needed to
> actually be binary. But hey, what do I know... :-)
>
>
> On 6/27/05, SteveKing <steveking@gmx.ch> wrote:
>
>>John Browne wrote:
>>
>>
>>>So, without branching/merging what I'm gathering is, you guys would
>>>assign *forms* to specific people, and let them be the only ones to
>>>manage those forms. They would have to manually keep separate copies
>>>of the forms based on whether or not they are working on a bugfix for
>>>a current release, or adding new functionality for the next release.
>>>
>>>If I go with this, would there be a better way to setup the repository
>>>layout other than the standard "/branches", "/tags", and "/trunk"
>>>directories? There would be no branching/merging, so should there be
>>>directories for each developer maybe? "/dev1", "/dev2", etc?
>>
>>I'm not sure, but are the frx files really necessary? I always thought
>>you could compile a VB6 program even without those. AFAIK, those files
>>are just auto-generated by the form designer for internal use (i.e. it
>>keeps the guidance grid, lines, ... but not the actual form).
>>
>>I may be wrong though...
>>
>>Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jun 27 19:44:40 2005