Version control, trac

Started by Nnidyu, September 16, 2008, 12:33:58 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

JanLo

#15
Hello,

you should definitely learn git one day. Its a distributed VCS - so you don't depend on some site. You just have multiple repositories with all holding the whole history and can synchronize changes between them in both ways. That's how the collaboration gets easier. Everyone can have its own repository, cloned from somewhere, work on it and ask you to sync the changes back if you want. Then you can totally transparent see all changes and decide which one you will take. Services like github just help to have on easy to access copy of the repository with some useful features around.

I, as an example, cloned the debian "upstream" branch from https://anonscm.debian.org/git/collab-maint/fet.git, made some changes locally and pushed it to github to https://github.com/janLo/FET. Now the code is on my laptop and on github and I do not depend on anything - and you can see the changes on github https://github.com/janLo/FET/commits/master, clone it grom there using "git clone https://github.com/janLo/FET"  on your computer or compare all the changes at once online https://github.com/janLo/FET/compare/upstream...master. you can even click "clone" on the github page, get your own copy of the repository there and clone from that.

This also helps you not making terrible mistakes: If you want to try a new git-feature, you can easily clone (or even copy) the repo and try the changes there.

When it comes to the sensitivity of the code in case of errors, there is a lot of room for improvements. I started some cleanup yesterday and may continue on the next days. I think you could easily reduce the codebase by some refactoring and add more type safety alongside with that so that the compiler can find more mistakes.

last but not least: I really know kdiff3, kompare, melt and all this diff tools. I work in software development for a long time ;) . But having a compare tool does not replace a VCS. You could even use kdiff3 as dill- and mergetool for git if you like it: http://stackoverflow.com/questions/33308482/git-how-configure-kdiff3-as-merge-tool-and-diff-tool :)

At the end: I understand your concerns. I just waned to give you an overview of some of the benefits. If you won't use it: ok. I'll try to work with what I have from the debian project and hope you will take at least some of my changes back at some day. I'll send them to you as patchset on top of the latest release if you want (that's another benefit of git: you could easily rebase your changes on the latest upstream version when this moves forward).

Thanks, Jan

Liviu Lalescu

Thank you, I read some of your improvements and they are nice. I don't agree with some (0==expression, I prefer expression==0, teacherName(), I prefer getTeacherName() and setTeacherName()), there is a small mistake (the +        case CONSTRAINT_TEACHER_NOT_AVAILABLE_TIMES: - you forgot to add TimeConstraintType:: before it).

The thing is that all such changes are critical and need a lot of time for checking. But I'll think about it.

JanLo

Hello,

Quote from: Liviu Lalescu on September 02, 2016, 11:07:52 AM
Thank you, I read some of your improvements and they are nice. I don't agree with some (0==expression, I prefer expression==0, teacherName(), I prefer getTeacherName() and setTeacherName()), there is a small mistake (the +        case CONSTRAINT_TEACHER_NOT_AVAILABLE_TIMES: - you forgot to add TimeConstraintType:: before it).

The thing is that all such changes are critical and need a lot of time for checking. But I'll think about it.

The links where only to show you how git can be used - I'm not finished with my refactoring but at 4am I stopped working on it to get some sleep ;) . The overloaded teacherName() is more common in the c++ world than getX() or setX(). But that's just personal preference. Both is better than having a public state without accessor functions ;) .

For the (0 == x) - I got used to this version because it prevents an accidental assignment when you typed only one equal sign because the compiler will complain about (0 = x) but not about (x = 0). But it's easy to change if you want, as its semantically the same ;) .

My goal is, to clean up the codebase a bit and separating the engine from the rest trough cleaner interfaces so that its easier to write a new UI or to use it as library in some other software. This should also open the possibility to write tests to prevent accidental changes in your algorithm.

Liviu Lalescu

#18
Quote from: JanLo on September 02, 2016, 02:21:43 PM
The links where only to show you how git can be used - I'm not finished with my refactoring but at 4am I stopped working on it to get some sleep ;) . The overloaded teacherName() is more common in the c++ world than getX() or setX(). But that's just personal preference. Both is better than having a public state without accessor functions ;) .

I did not know this. It is maybe better as you say.

Quote
For the (0 == x) - I got used to this version because it prevents an accidental assignment when you typed only one equal sign because the compiler will complain about (0 = x) but not about (x = 0). But it's easy to change if you want, as its semantically the same ;) .

Yes, I know that, but also in the majority of the cases if(x=0) will trigger a compiler warning, and I prefer to have code readability.

Also, another thing, I prefer to use tabs, not spaces.

Please note that I did not promise to take your code  :) . It is a lot to check and the changes are critical.

Edit: Another idea would be for you to use only the generate.h and generate.cpp and generate_pre.h and generate_pre.cpp, and derive your own additional code. The needed variables are in the beginning of the generate_pre.h. Because what you intend to change in the official code has that much to change that it might be better to start from scratch.

rodolforg

Well, I haven't see this before I start...

Here are my repositories:
https://bitbucket.org/rodolforg/fet
https://github.com/rodolforg/fet

I hope I can contribute to this project.
My goal is to provide unit tests to check the engine status and avoid break changes.

Liviu Lalescu

Thank you! But I am not experienced with this kind of collaboration. I hope I will learn something from your work.

For Brazilian Portuguese corrections, I think the best is for you to contact the Brazilian Portuguese translator.

rodolforg

Quote from: Liviu Lalescu on September 20, 2016, 10:38:56 AM
Thank you! But I am not experienced with this kind of collaboration. I hope I will learn something from your work.
I know this feeling...
If you want to learn git, I recommend this "e-book": https://git-scm.com/doc .

If you choose to not clone my repository (= have a local copy of my changes), I can provide you patch files of any commit (= set of changes I've done) you want.
This way you can merge with your own source code.
The patch file is easily created by git, as well it is to merge and check merge conflicts, though.

Quote from: Liviu Lalescu on September 20, 2016, 10:38:56 AM
For Brazilian Portuguese corrections, I think the best is for you to contact the Brazilian Portuguese translator.
Thank you. Done via forum.

Liviu Lalescu

Quote from: rodolforg on September 20, 2016, 01:17:08 PM
Thank you. Done via forum.

Thank you! I told khemis to look at that topic.