About events

How NOT to take part in the events:

  1. If you want to win, don’t bother.
  2. If you think events are something you should get, because you are kewl, don’t bother.
  3. If you think that prizes in events are for free, you’re wrong and don’t bother.
  4. If you want to take part in event just to bitch at prizes, DO NOT bother.
  5. If you think that the hints should give you precise walkthrough, guess what? – don’t bother!
  6. If you are not used to use the content of you head to the purposes Mother Nature created it – don’t bother!
  7. If you’re not able to read and understand hints – don’t bother!
  8. If you think you’re too 1337 for events, don’t bother!

How NOT to host an event:

  1. If you think that everything will go as you planned, you’re wrong.
  2. If you think that everybody will be happy with prizez, you’re wrong.
  3. If you think contesters will understand your hints and follow them, you’re wrong.
  4. If you hope to hear a ‘thank you’, you’re optimists.
  5. If you are not ready to read complaints, bitching and ‘This should be done this way, not as it was’, contests are not for you.

How to take part in the events:

  1. If you want to take part in the event for fun, not prizes. You’re precious, hope you will do it each time.
  2. If you do use your brain, read hints and do not whine – hope you will take part in all events.
  3. If you’re able to have fun without getting prize – :thumbs up:
  4. If you are able to give sensible critic with good arguments, I bet contest holders will love you.

How to host an event:

  1. Be ready for frustration.
  2. Be ready for bitching.
  3. Be ready for disappointment.
  4. Be ready for nobody understanding your hints.
  5. Be ready for huge costs.
  6. Be ready for everything going wrong.
  7. You know what? SCREW it, go and have a beer with friends. It’s surelly better idea.

Working with svn

When you manage a project with svn there are a lot of things to consider: how you create the repository, what external resources will be imported in the repository. Basically  it’s a constant job on how to organize things better to keep developers happy.

After lots of try/fail cycles i came to the conclusion that for linux distribution the best approach would be a tree like this

server
-> bzip2
* trunk
* tags
* branches
-> atk
* trunk
* tags
* branches
-> tfm-filesystem32
* trunk
* tags
* branches
server64
-> bzip2
* trunk
* tags
* branches
-> atk
* trunk
* tags
* branches
-> tfm-filesystem64
* trunk
* tags
* branches

What is wrong with this structure? In time a developer will update bzip2 from server 32 tree but will forget or won’t have the time to update server64 tree. So the trees will not stay in sync. And this is bad because it might happen that the projects will have different sources.

What can be done? Use svn:external declarations. First idea was to create a common tree and create externals from both server and server64. But this way we will have 3 trees and lot of work to do. And it will become hard to manage. Another approach was needed. We decided that server is the main tree. In the server64 tree we declared bzip2 to be external and pulled from 32 bit tree.

This way if a developer commits a change will go in both trees simultaneously.

How to use svn: external? Let’s take for example bzip2 from server64

svn del bzip2; svn commit ; svn pedit svn:externals . ; svn up ; svn commit

and when editing svn external you should add a like like this:

bzip2 https://svn.tfm.ro/tfm/server/bzip2