Messages

Hello,

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.

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

sorry, but i don't have time to upload and learn that. so what do you suggest who should do that work? will you always upload? i haven't got time to care about that.

It's no problem for me to do that but that will not solve the problem. My main point was, that you should refer to a official source on your website, because when I search on github, I get at least two repositories containing FET in some state in history. I'll never know whick is the right one.  You could even refer to the debian VCS of FET.  Just a source where people can easily base their work on and can be sure that this is the latest available version.

my pupils are not coders :-)
that are "normal" pupils. on a "middle" school. Max age is around 16 years. They don't learn coding at my school. "Just" Mathe, German, English, History, Sport, ... but not coding.
Even they never code, that guys are clever enough to download and extract.

So you see my point?!

I totally got it - and even if I think that they do not learn to code is a sad fact with the school system - it's not an issue for a VCS. They can easily continue to download, extract and do whatever they want with the tarballs. (But besides that I would also say, that C++ is not a good language to learn how to code in the first place )

I understand the advantages you tell me, but you forgot the disadvantages. You can do all that stuff only if ...:
- ... you know how to do it
- ... you do it (i saw several projects on github that didn't add extra information. so in fact some of your advantages are only true if you add that information. that mean more work.)

You just give the opportunity to people who are regular software developers to use it. You don't have to use it for your own at all. You can just stick with your release tarballs, commit the state of the release at one big commit and put it somewhere public. With that your release process will be extended by just one "git commit" and one "git push" - and if you wont remember the commands you could easily use a UI for git. Nothing changes except that you're offering another way to access the code .

For me it would just be more convenient to have a official git source to clone from. If not I will just make a repository for my own purposes, import your latest release and maybe send patches of changes back. In fact the debian maintainers had already done this: https://anonscm.debian.org/cgit/collab-maint/fet.git

I have not looked at github at all because I looked at the official site for a source link. That's the problem with github repos that are created by people who miss official sources: they create them for their needs, get their work done and then orphan it. When you have a maintained "official" repo you can clone from it and everyone searching for it can easily see where it original came from. And as said, there are even a bunch of graphical interfaces for git if you cannot remember the commandline.

Another benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.

even my pupils are clever enough to download and extract a file. but no one of my pupils is clever enough to use a version control system. so this is in fact a point against version control.

My point here was, that you can search the code and point (link) to locations in it. I did not say, that a VCS should replace release tarballs. You can always have them, it's no problem with that. A VCS will just be a separate and more transparent way to distribute the code. You can even set release tags within the VCS to show the state that represents the code in a certain release. With this its easy to get a diff of the changes to spot regressions if one experienced one.

It would also not prevent someone to just download a tarball, make changes and send it (as a whole or as patch) back to upstream. In fact this is close to the way he linux kernel uses git as VCS: you send your commits to the VCS as set of patches to the subsystem maintainer who integrate them. You don't have to force anyone to use a VCS when you provide a public repository. You just give the opportunity to use it to people who are used to collaborate this way (software developers ). I mean, you can try it. It will not change your software in any way - but I think it gives you the possibility for easier collaboration - at least with some people.

I would also think that your pupils will be clever enough to use a VCS if someone shows them the benefit. And if the work on the software should give them an insight in today's software development techniques it would be a huge benefit to show them how collaboration in this field works today .

Hello,

it's 8 years later now. Have you reconsidered your decision not using any version control (and a public platform about that)? It may give your software new pace as it makes it easier for every interested developer to fork it, work on it and contribute the changes back to you.

It's not about giving up control or give someone else the right to make changes without your knowledge. In fact it makes it more transparent for you and everyone else to see what exactly has changed (and why). There is also a lot of easy to understand documentation and tutorials around describing the different VC systems. Also the various platforms make collaboration a lot easier.

With github for example you have a fork and pull-request system, where people can fork your code with one click, make changes in their own repository and contribute it back via a pull-request. This gives you an entry in the bug tracker where you can easily review all the changes and discuss it with the contributor. When you think, the change is ready to be merged into your official codebase, you can do this either locally via git with one click within the web frontend of github.

Another benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.

Thanks, Jan