Log in

TelFOSS Meeting Report: Sawyer about Version Control Systems - Shlomif's Technical Posts Community [entries|archive|friends|userinfo]
Shlomif's Technical Posts Community

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Links:| Shlomi Fish's Homepage Main Journal Homesite Blog Planet Linux-IL Amir Aharoni in Unicode open dot dot dot ]

TelFOSS Meeting Report: Sawyer about Version Control Systems [Apr. 27th, 2010|12:54 pm]
Shlomif's Technical Posts Community


[Tags|, , , , , , , ]
[Current Location |Home]
[Current Mood |productive]
[Current Music |DXX - Infinity (Galgalatz Radio)]

Here are some notes from the Tel Aviv Open Source Club's meeting last week, in no particular order. They are not exactly a report, but are probably better than nothing. I originally posted them to the club's mailing list and forwarded them to to the Perl-IL mailing list, where it sparked a small (but funny) discussion. I hope to expand upon them in this blog post.

  1. About 20-30 people came in my approximation, some of them a little late, so it was pretty successful. So hopefully it was a good decision to find a venue which can afford starting at a later hour. We'll see if the trend of successful presentations can continue.

    I think I recognised most of the attendees, but there were some new faces, which is a good thing.

  2. Sawyer gave a very good presentation in my opinion, and I've learnt some new stuff about git there. There was some good involvement from the audience. Next time, I'll try to pass the baton to a different lecturer, because I think Sawyer has been giving too many presentations lately, and we need to see some fresh blood.

    At the moment we only have one proposed presentation for June (by cool-RR / Ram Rachum ) and he still noted he may need to cancel. I've been considering to prepare a presentation/demo about jQuery and also proposed to give a "Bottom Up Subversion" presentation/tutorial. I'm not a good speaker so I'd prefer if someone can give it instead. We can also have a session of short, volunteered presentations on the spot (lightning talks or somewhat longer.).

    Nevertheless, it would be preferable if someone will volunteer to give a presentation.

  3. Some logistics about the room - there is a keyboard and a projector, but no screen. One can connect a laptop. The computer runs Windows , and we're not sure if it has OpenOffice.org. There's an Ethernet connection and also some Wifi networks.
  4. Sawyer mentioned the fact that from his experience creating a branch in Subversion (using svn copy) was time-consuming for him ("I went to prepare coffee"). This sounds strange to me, because branching and tagging in Subversion are reportedly cheap, constant-time ( O(1) ) operations, and I've verified it from what I've read about the Subversion internals. I often branched the Freecell Solver's trunk which is 26M in size and it didn't take more than a few seconds. svn.kde.org has many branches and each of them keeps the entire KDE source code and is positively huge with 100s of megabytes of files.
  5. I mentioned the mini-repository Subversion pattern - each with its own trunk, tags and branches which can be seen in action in the Web-CPAN repository. This is a single subversion repository with several mini repositories - one for each project. It can be done in git too by keeping each project in its own sub-directory, out of the top-level sub-directory.

    I should note that I also eventually decided against putting the files of the program directly on the trunk, but rather always put them under a sub-directory of the trunk, so if I need to add something else, they won't clobber the trunk.

  6. There was a short discussion about whether version control systems are using databases as their repositories' back-ends. Someone said he wouldn't trust a VCS that uses an off-the-shelf database, and I'd like to comment about that. The first thing that one should note is that like "Practical mod_perl" notes many data storages are in fact databases without us really thinking about them. Even the file-system is a database that maps filenames to the file contents. Furthermore, Subversion requires a transactional database for its use: it started from Berkeley DB (which is a database with some accepted and deliberate philosophical limitations), and then got the ability to use a backend called FSFS, which is a specialised, ad-hoc, database coded specifically for use by Subversion; and the Subversion development team have a distant goal of also creating an SQL-based backend for the repository.

    That's not all: Monotone has been using SQLite since its inception as its local storage backend, and reportedly ClearCase is using a database called "Raima". And naturally, I expect that even git, Bazaar, Mercurial and similar version control systems implement a database storage of some sort internally.

  7. We discussed the Simple Simon solitaire, which I've introduced Ido (ik) to and to which he became addicted to lately. I've ranted a bit about how "Solitaire" (or what the British call "Patience games") is actually a generic name for single-player card games, and that what Windows calls "Solitaire" is actually just some variants of Klondike Solitaire.

    We compared and contrasted both PySolFC and KDE 4's KPatience.

    The one who introduced me to Simple Simon was Stephan Kulow of KDE fame, who when I told him that I'd like to adapt Freecell Solver to solve Klondike said that "I don't think the world is ready for that." and then added that he could really use a solver for Simple Simon. After playing a few games of Simple Simon, and experimenting a little with the fc-solve C code, I was able to create a satisfactory solver, but then I also started to like Simple Simon and played a lot. And it was contagious as my mother and my sisters also started to play it.

    Right now, the KPatience's Simple Simon demo ends up in many practically infinite loops of no apparent objective. I hope to work on converting it to use my solver instead (which does not exhibit this problem), but it will take some work.

  8. About 5 of us went to eat at Spaghetim (an Italian restaurant in Ramat-Gan) after the meeting. Besides me, there were two Perl programmers ( http://szabgab.com/ and Sawyer, who was the presenter) and two Python programmers and I was appointed as the referee. We were able to explain some stuff from both languages to the other party.
  9. Szabgab mentioned that when he asked some people he gave training to if they know Perl, they said "No, I can only read it.", which to him seemed to imply that maybe Perl's reputation as a write-only language was unfounded.
  10. When we discussed Ram's Garlicsim ( http://garlicsim.org/ ) he mentioned that he is mostly a web contractor, but that he would prefer to be hired for writing simulations. Then Sawyer mentioned that often an invention brings a necessity, which reminded us of the book "Guns, Germs and Steal". It is highly recommended. Then we discussed some other books by the same author and I ended up saying that I've also read the book "The Origins of Conciousness In the Breakdown of the Bicameral Mind" by Julian Jaynes, which I enjoyed and found of a similar interest to "Guns, Germs and Steel" because of its philosophy of taking a bird eye's view of human history.
  11. Also in the after-meeting, we discussed automated tests and test coverage, and someone said that it may not be indicative of how well all the edge cases were dealt with. For example we can test that the tests cover the expression "z = x / y", but it won't warn us that we dealt with the case that "y" is zero, which we should. Someone noted he likes the green indication that he has 100% test coverage. On Perlsphere Ovid recently wrote that a general piece of advice is that one should not strive for 100% test coverage.
  12. We saw a demo of GarlicSim (which is LGPLed), and its Wx-interface (which is at the moment not open source, but has the source available for download under restrictive terms). Ram showed us how he started a simulation where the simulator calculated a line, and then it was possible to branch it into a different line of execution and continue from there. He intends to continue working on GarlicSim into the near future and then hopefully be able to give some presentations about it to the local open-source clubs.

To sum up, it was a great meeting, and I hope this trend will continue.