If another vote for multi-development will help speed things up – please accept mine. We are currently doing the multi-developer import-export thing and its a real drag. Plus, we are using global methods that are used with every single form, and modified when each new form is created, so its mighty tricky not stepping over each other.
Multi-devleoper functionality would be a BIG improvement to this product.
Hello!
Recent experiences with the merging of repositories have been very unpleasant so I have to re-activate this topic. We are using the technique described in page 1 of this thread (master/slave), but we keep getting unexpected results.
We currently don’t see a reliable way of working together on one solution, even if working “disciplined” in a way that we try not to touch things that don’t belong to the current task. So my question is: When will there a solid way to put more than one person to work?
We have a big project with a tough schedule and are getting pretty nervous because we just cannot put all our energy on the actual project. We are loosing time and work. Is there any news?!
Thanks
Patrick
Here is my vote too!
Count my vote also.
This is a very important matter for us.
Please take it under consideration ASP.
We have planned module based development for Servoy 2.5 as it will still take a while before 3.0 with it’s true multi-concurrent-developer support will appear. With module based development you will be able to work with multiple developers on a solution by dividing it into modules. Development of Servoy 2.5 has already started and we hope to have it available before or in Q1-2005.
Stuff our lawyers make us say:
No rights can be derived on features and timeframe of future versions based on this posting, etc, etc.
Hello,
thanks for the reply. On one side, this is good news, on the other, it is not simply because it will take a while.
To survive in the meantime: I think it would help if we knew better what rules apply on synchronisation of repositories. Could you explain what exactly overwrites what based on what rules?
I am also very interested to know a little more about the planned module based merging you talked about if possible. I just think that this is a critical area on which we might have some ideas to share.
The other point that interests me is my question above (from Aug. 8th): would it possible to export only parts of a repository? I think this would be an extremely useful feature not only as fars as logic is concerned but also data. Our solution needs some data to perform properly and I am not quite sure about how I will update that data, for example.
I think this whole issue will be getting more and more crucial as people will start to deploy more solutions. Maybe it’d be helpful to have a broad discussion on needs/problems in this matter?
Thanks
Patrick
I am also very interested to know a little more about the planned module based merging you talked about if possible. I just think that this is a critical area on which we might have some ideas to share.
To come back to that point, if I may: we have a customer that wants to integrate his own development into our solution. They buy our solution for their “general” problems and want to develop their own modules for their business specific matters.
Right now they work with Servoy as if our solution didn’t exist hoping that one day these two solutions can be merged. What can I tell them? Is this the way to do it having that coming feature in mind? Or: how should we go about this?
Thanks
Patrick
patrick:
I am also very interested to know a little more about the planned module based merging you talked about if possible. I just think that this is a critical area on which we might have some ideas to share.
What would you precisely like to know? And, yes, please do share your ideas about it.
patrick:
The other point that interests me is my question above (from Aug. 8th): would it possible to export only parts of a repository? I think this would be an extremely useful feature not only as fars as logic is concerned but also data. Our solution needs some data to perform properly and I am not quite sure about how I will update that data, for example.
With modules you can choose which modules you want to bundle in a solution.
patrick:
I think this whole issue will be getting more and more crucial as people will start to deploy more solutions. Maybe it’d be helpful to have a broad discussion on needs/problems in this matter?
Yes, and this is the right place to share your thoughts about it so go ahead and let s know what you need.
Before we discuss things that we might be using tomorrow we have to see how we can survive today
We had to use repository merging again, simply because we need two people working at the same time. So we used the typical master/slave construct. Since slave in this case was changing the look of a lot of forms, master sticked to one or two forms.
After merging using the import version (slave, who had more changes), almost all changes of master were gone. On one form he created several methods. All of them were gone. Slave (which was me in that case) had never even seen that form, so I did not touch it. How could there be a conflict, then? As far as the merging logic is supposed to work, it should have left this form alone since it was not touched in the import version, shouldn’t it?
How can we savely go on to work? We need some sort of solution for this problem. This is creating a big time stress. We thought we’d be able to at least merge our work (if not working together), but it looks like we are not. We don’t have the time to control every single thing we did, either. But we just can’t trust merge results.
I am a bit helpless with this issue. The only thing I see right now is one person working at day time, the other at night.
Maybe somebody could comment my suggestion from August 8th of specifying which parts of a solution to export (including data). If Servoy cannot handle merging reliably at least we ourselves can take care of what is going on.
Plase HELP!
Thanks
Patrick
Here are our experience, working at two simultaneously on the same repository.
Working each on separate parts (modules) let us work without actually “loosing work”.
The major drawback of this method is that we are often stuck in the middle of a debug or other operation by (I suppose) interlocking. The lock disappear when the other developper quit and restart his servoy developper.
As far as I can figure it out, we can work on separate forms/methods without triggering much interlocking as far as we do not change one of the following: global methods and variables, relations, data structure, calculated fields.
Respecting this and never opening other’s job in layout mode let us have programming sessions from 10 minutes to about one hour without interlocking.
Doing this, I only lost work once, when inadvertently modifying a global used in several relations.
As a matter of fact, this is far from a multiuser programming interface, but it let us work two at the same time although we tend to program at diferent time in order to avoid troubles. Yes we too thought making two shifts…
We have done that, too, and had the impression that it “sort of worked”, although we also experienced some locking problems. There was, however, a statement from Servoy somewhere in the forum that this should not be done.
We are willing to live with a locking problem as long as we don’t seriously damage things. So if working on one repository is save, we would choose that option. Is that save?
Thanks
Patrick
Just spent almost 2 hours figuring out what was lost during the last merge of repository. This is impossible. So I would prefer to work on one repository.
Could anyone from Servoy please describe what can possibly go wrong if two people work on one repository?
Thanks!
Hi,
Working on one repository can cause lots of locking problems. Furthermore, changes made by one person are not visible to the other person without restarting Servoy devoloper (due to caching and lack of change notifications to other developers). Also, it is possible that the repository is put in an inconsistent state when a new release is made in one developer while another developer is still working on an old release. There’s probably more trouble as well. Servoy Developer was currently not designed for multi-developer work. We understand that it is a very much desired feature and are putting much thought and effort into making this available in the future.
As far as merging is concerned, it is important to ALWAYS use import/export to transfer solutions. If you are sure this is the case and it really isn’t working as expected, please send me an export of both the master and the slave solutions (before the merge), and if possible a database dump of the repositories as well. I will try to figure out what is going wrong, why it is going wrong, and see what we can do to fix it. If it is a bug in the Servoy code, I will fix it ASAP. I will also do some testing on my own to see if I can see any problems.
Bottom line is that the crude (at form level) merging should work properly and you should not have to resort to dangerous things like working on the same repository with 2 or more Servoy Developers.
Note: it’s probably a good idea to make a backup of the repository before attempting to merge an imported solution.
Hope I can help,
Hello Sebastiaan,
thanks for the answer! As far as working on one repository is concerned, it looks like the best solution for us. Locking is not a big problem, we will not create releases and visibility of changes is not so bad since we work on different areas. I wonder, though, what “more trouble” might be. Anyway, merging is currently a lot worse.
I am also interested, though, to get merging to a point where I would say it does the right thing. Especially, where we will have similar issues when a module feature is available, since that will also envolve merging, right?
To me it seems that there might not even be a bug in merging itself but a problem in the underlaying logic of tracking changes. It would be helpful if you could describe on what bases Servoy decides what version to use, for example:
The whole issue is difficult to describe, since many actions/options are envolved. We had situations (as described in this thread), where person B worked on a form that person A never touched. When merging person B’s solution into person A’s, all newly created methods of person B were gone.
Yesterday I deleted and created labels etc. on a form that my colleague surely looked at, but did not change. When I imported his solution into mine, I had my changes merged over his old version. The result was for example, that labels I had deleted were there plus the ones I had newly created.
So if possible, please describe in as much detail as possible the merging process including the “rules” for tracking changes. If we understand exactly what happens, we can try to avoid situations that are correctly handled by Servoy but unwanted or track possible bugs. Right now, we pretty much have a black box and a hard time checking the results.
Thanks!
Patrick
Hi Sebastiaan,
Nice to get ‘official’ informations through your post. We had deduced most of your remarks concerning working several on the same repository by trying and studying servoy repository internal data model.
For now, we will probably continue to work the same way until first official release of our solution.
In fact, we happens to better understand what happens when working like this as our understanding of the import/merge model is limited as stated by Patrick.
We hope having multi-dev option available after that release (end first quarter 05). Otherwise we may have to stick on the import/merge model at that time.
I will try to post trick and tips (and misshappens too) about working several on the same repository from now, unless you avise me against promoting this ‘not supported’ feature.
Have a nice day.
Sebastiaan,
Where in the documentation can I find the steps to follow to have master and slave solutions and merge a change made in one back to the other?
I presume this has to do with solution “revision history”? How do we control/use this?
Thanks,
Neale.