Temple of The Roguelike Forums
Development => Programming => Topic started by: Krice on November 04, 2012, 06:39:14 PM
-
Is there such thing? I don't want anything like source control (too difficult and hacky), just store and possibly share source code (maybe with new version of Teemu).
-
Google drive, drop box, wuala, ubuntu one.. There are number of solutions designed to just store and share arbitary documents. You miss most advantages of source control, but set up and usage is easy.
-
I use dropbox. You can choose to "share" a folder with other people you want involved and the files sync automatically.
-
Using version control (I think that's what you mean by source control) is worth it. I find git hard to grasp, but Subversion is fine.
-
Try TortoiseSVN, it's very easy. The power of version control can't be overestimated. Whenever something in your code breaks, you can review the changes and find the bug. Without version control all you can do is guessing.
-
Whenever something in your code breaks, you can review the changes and find the bug.
I don't have bugs. At least bugs I don't know. The idea of finding bugs by tracking changes sounds primitive. I'll try Google Drive, I have an account for Google anyway.
-
I don't have bugs. At least bugs I don't know.
So you don't know that you have bugs. One day you will learn of their presence (most likely when someone else will attempt to run your code) and you will regret not having version control. Finding bugs by tracking changes may indeed sound primitive, because it *is* primitive (although I'd choose a better word: easy). The best thing about this method is that you have the complete information about what could have caused your program to fail, so that if your program crashes at random places because of memory corruption, you know where to start looking for a bug.
-
I don't have bugs. At least bugs I don't know.
So you don't know that you have bugs. One day you will learn of their presence (most likely when someone else will attempt to run your code) and you will regret not having version control. Finding bugs by tracking changes may indeed sound primitive, because it *is* primitive (although I'd choose a better word: easy). The best thing about this method is that you have the complete information about what could have caused your program to fail, so that if your program crashes at random places because of memory corruption, you know where to start looking for a bug.
I, like Krice, am a real developer, and our versions play with permadeath on!
-
so that if your program crashes at random places because of memory corruption, you know where to start looking for a bug.
In case of C/C++ you don't know. It can be anywhere. Version control doesn't help you unless the bug actually was programmed recently which is just one possibility. But I really don't need version control, because my source code is quite bug free. These days I don't even need to use a debugger. I've learned to take care of the weak points of C++ which usually produce bugs.
-
I recommend version control. You pick up the basics of git pretty quickly, and it's another tool in your belt.
Plus it allows you to safely experiment and spike out new ideas with a safe roll-back point. Then when the ideas are more fleshed out you can roll back and integrate the features properly.
Most of my code tends to be bug free due to being very loosely coupled with heavy test coverage (so I get near instant feedback if things are not as expected, and can track down issues quickly), though things will still occasionally slip past.
Plus, I like the peace of mind of knowing if things blow up I have a relatively painless way to roll back.
Also issue trackers are a good way to map out features to be implemented, though admittedly not intended for this and github's issue tracker is no JIRA...
-
zip
As always,
Minotauros
-
In case of C/C++ you don't know. It can be anywhere. Version control doesn't help you unless the bug actually was programmed recently which is just one possibility.
Even if this happens, having version history is still much better than nothing. You have, say, 80% certainty that the bug is in the last revision, 40% that it has been made in the revision before the last one, and so on. Without version control you have 100% certainty that the bug is in your code and that's all you know :). However, memory errors are not so very common if you're an experienced C++ programmer and the real reason why you should use version control is that it remembers all the small changes that you don't. How many times did it happen to you that you realized a feature had been working in the past, but now it's broken? What do you do in such cases? Look at file modification dates to see what has been changed quite recently? Try to guess? Modify a randomly chosen file, hoping that it will fix the problem?
-
How many times did it happen to you that you realized a feature had been working in the past, but now it's broken?
How about zero times. If I say I don't need version control it means I don't need it.
-
How about zero times. If I say I don't need version control it means I don't need it.
No, it means that you don't realize you need it (yet). Or maybe you're working on some 7drl that has roughly 2k lines of code.
-
Or maybe you're working on some 7drl that has roughly 2k lines of code.
Kaduria has 44K and Teemu 19K.
-
Kaduria has 44K and Teemu 19K.
The larger project seems to be abandoned, why did you stop working on it? Wasn't it because of bad code?
Untitled/Fame has comparable size (47K without GUI framework and libraries). When it exceeded 30K (a year ago), I decided to start using version control. Before that point I also thought I didn't need version control for just one programmer. Now I can see how wrong it was. Give it a try, it costs nothing. 20 minutes of setting things up, then profits.
-
The larger project seems to be abandoned, why did you stop working on it? Wasn't it because of bad code?
It's not abandoned and the source code is almost entirely modern data-driven C++. It's much better than you can imagine with your limited abilities.
Untitled/Fame has comparable size (47K
Is Fame a 7DRL?
-
Untitled/Fame has comparable size (47K without GUI framework and libraries). When it exceeded 30K (a year ago), I decided to start using version control. Before that point I also thought I didn't need version control for just one programmer. Now I can see how wrong it was. Give it a try, it costs nothing. 20 minutes of setting things up, then profits.
I had svn/tsvn set up in under 10 minutes iirc. It's a solid VCS, and tsvn is especially nice because it integrates with the Windows GUI. I can only recommend it, been using it for years.
-
Is Fame a 7DRL?
More like 12YRL :).
I had svn/tsvn set up in under 10 minutes iirc.
That's right, and another 10 minutes for configuring SvnServe, so that my 2D artist can use the same repository, too.
-
Untitled/Fame has comparable size (47K without GUI framework and libraries). When it exceeded 30K (a year ago), I decided to start using version control.
I was reading Fame thread and looks like you have problem with bugs. So, version control didn't take care of them, right?
-
I was reading Fame thread and looks like you have problem with bugs. So, version control didn't take care of them, right?
Has anybody said, in this thread or anywhere else, that version control automatically deals with bugs? It just helps programmers, it doesn't replace them.
-
that version control automatically deals with bugs?
Isn't it exactly what was said: when you detect a bug you can go back to earlier code that didn't have it. It's automatic, you don't have to find the bug at all. However I believe it's not that simple.
-
Isn't it exactly what was said: when you detect a bug you can go back to earlier code that didn't have it. It's automatic, you don't have to find the bug at all. However I believe it's not that simple.
You can do that, but it wouldn't fix the bug. You only revert your changes if you feel they were a complete disaster. If you need to fix a bug, it might be useful to compare your current revision of the code with some revision from the past. This is what I meant.
-
To store your source code you should use a 3.5" floppy.
-
To store your source code you should use a 3.5" floppy.
Kaduria has seen that time when 3.5" floppy was a viable storage unit. I still have those disks somewhere with early versions of Kaduria.
-
To store your source code you should use a 3.5" floppy.
Kaduria has seen that time when 3.5" floppy was a viable storage unit. I still have those disks somewhere with early versions of Kaduria.
Aww. I grew up with these sweet little things... :) I even have an old 8" floppy on my wall that's older than me.
-
To store your source code you should use a 3.5" floppy.
Kaduria has seen that time when 3.5" floppy was a viable storage unit. I still have those disks somewhere with early versions of Kaduria.
Aha! That's why you're so averse to revision control. Modern computers use so-called "hard" disks, or even "networks" that make tracking changes much faster now than digging through your meticulous stack of floppies.
;)
Once you get used to how fast these new technologies work, revision control can really save you time developing & experimenting!
-
In junior high they told me the 3.5" floppy was a 'hard disk'. The 8" was a floppy disk.
My 'computer' class was just a typing class, and my teacher was a hunt and peck master.
-
that version control automatically deals with bugs?
Isn't it exactly what was said: when you detect a bug you can go back to earlier code that didn't have it. It's automatic, you don't have to find the bug at all. However I believe it's not that simple.
In theory - and there are systems that do this - you can automatically remove a bug if you combine `git bisect` with unit tests. I have never met anyone who had such a sophisticated setup but my linux magazine tells me some people do that.
What you do with git bisect, is you make a binary search for the one change which introduced the bug. You start by telling git the version number of the working code, and a version number for broken code. And git will interactively let you binary search through the versions in between until you find the one commit, which introduced the bug.
This is much more sophisticated then what you usually do. Even if you have SVN or CVS or whatever: step back in time, undo change after change, until you find a version which works; then look at what you changed... that's often 99% of finding a bug.
-
In theory - and there are systems that do this - you can automatically remove a bug if you combine `git bisect` with unit tests. I have never met anyone who had such a sophisticated setup but my linux magazine tells me some people do that.
Damn, this is crazy or I am missing something here. If one is able to write unit tests that would detect a bug, why not to run them *before* the code is committed?
Aww. I grew up with these sweet little things... :) I even have an old 8" floppy on my wall that's older than me.
That's bigger than my screen! :) I remember 5.25" disks, but I was afraid of storing data on something I could bend. 3.5" floppies were fine, but they would always have some bad sectors every time you moved them from computer to computer, so it wasn't the best possible way to store code :).
-
In theory - and there are systems that do this - you can automatically remove a bug if you combine `git bisect` with unit tests. I have never met anyone who had such a sophisticated setup but my linux magazine tells me some people do that.
Damn, this is crazy or I am missing something here. If one is able to write unit tests that would detect a bug, why not to run them *before* the code is committed?
It doesn't have to be a unit test and sometimes bugs do slip through, regardless of automated testing. Also, it doesn't automatically remove the bug, but find the commit where given test fails first time. But, if you write consummate code, such a hackery is not needed :)
It still feel a lot more adventurous when I have version control to back me up. It's easier to experiment with the code and throw away stuff that I don't like and keep the stuff that I like. Sharing with friends and strangers is a breeze.
-
It still feel a lot more adventurous when I have version control to back me up. It's easier to experiment with the code and throw away stuff that I don't like and keep the stuff that I like. Sharing with friends and strangers is a breeze.
good point!