david:
Am I completely wrong about this? I mean we use SVN, think it’s a great concept, and even like it half the time – kind of a love/hate relationship. Not sure about subclipse, maybe that will solve everything.
dont know if for you subclipse or subversive would make a great difference, its kind of exactly the same, only a bit different in some ui stuff i think
Prolem with subversive is that it has some or at least one big bug, that when your eclipse crashes somehow and eclipse wants to recover it the next time you start, subversive start doing illegal stuff on different threads and because of that
you are not able to start servoy anymore.
i am personally more a fan of subclipse (use it already for years, i am signed and faxed a contract because my patches where a bit to big to be applied without some legal consensus ![:)]( "Smile")
) it is also from the makers of svn itself.
No i dont say that svn is the holy grail, dont think so, it has some issues here and there.
I am also looking into GIT thats really powerful, but as long as there are no good eclipse integration plugins i wont touch it.
david:
I think my main frustration is that nothing about it comes naturally. There are 2 perspectives, 50+ triggers points that are all in different spots so my eye is always searching for “Team…” in the context menu, I have to keep a cheat sheet around to remember how to merge database changes (I always forget the order in which I have to do the process), rolling back to a previous “release” is a challenge, terminology is all confusing (“Checkout” command from the “All solutions” node for example), and probably a few other things I can’t think of right now. And this is after setting SVN up which takes two pages of step-by-step notes.
The natural order of things should always be
first do an update, handle all merge conflicts, then when you are in a state with only outgoing changes do commit it.
The checkout command from the all solutions node is already enhanced a bit now it say “checkout from servoy repository” to be more clear what it really does.
SVN checkout can be done through File->import->SVN->Checkout projects from SVN
But i never use that, i always go through the SVN Repository view, select the dir/folder i want to checkout and tell it to checkout.
david:
And now with the file system change from Servoy 4 to 5, renaming forms will mess up an SVN repository just like that. On the local side Servoy renames the form file and javascript file, but keeps the same UUID in both cases. Commit to SVN, and now you have two form files and two javascript files with separate names but the same UUID. Another developer updates their local from SVN and immediately starts seeing duplicated objects in the Solution Explorer due to the same UUID in multiple files. Try this with multiple developers cranking full out at the same time ![:)]( "Smile")
and this is weird, UUID things or not shouldnt matter (thats just contents of a file), because you rename and a rename should be: move or lets say copy and delete
and that last word is the key, “delete” if you rename you should also see outgoing deletes of the previous file. That should be committed in one go to the svn repository.
Try for example to rename something, then look in the synchronize view (i always work through the sync view at all times, never just do updates or commits from the projects)
then you will see 2 things of that file one with a minus symbol and one with a plus symbol. When you commit that as once and a co worker checks it out
then it will first delete the current file and then get an update of the renamed file… So your co worker shouldnt have duplicate files.
SVN is smart about this rename, it knows it was a rename from a specific file so you keep everything like history and the ability to go back…
david:
SVN does take a day-long training session to get up to speed on it. Says something about it doesn’t it? Just because it is powerful doesn’t mean that it’s the best way or the easiest way. If Servoy hadn’t put all methods in one file would you need object level synchronization? And it would be a bit weird to use object level synchronization on form files.
that would be quite horrible performance wise and disk space wise
We didnt change the file format we had in 4 for nothing in 5.
Large solutions where crawling because of the many many many files. And a solution that really was lets say 70MB was 1.2GB on disk because of the sectors and clustering.
So making all the script methods also a file by itself would even make that situation way worse.
Also i dont think that most people would way that is handy. Because i think most of us do edit a file things at once in a file. now you have a file per form so you can quickly with page up and down or CTRL-O go through the file
If you had a file per method you would have had to jump all around through editors and the editors that you would need to have open would just explode.
david:
In my opinion, if we had a way that was extremely easy for 90% of what we needed it for, we would use that process almost exclusively over something quite complex that does 100% of what we needed. For the other 10% missing in the first approach, I would just use an external SVN program with a much better interface. Sort of like using external SQL editors for doing stuff that the Servoy SQL editor is not great at.
you are fee to use a external SVN program if you like that one better. Thats not a problem
EDIT: even for one file (per method) you could have if you really work with 5-10 men on a solution have changes on the same file. You never can say that wont happen.
