I started to document some exceptions or special cases of network during installation. But this is I already know (I don't know what users don't know or wants to know ;-)) so if anybody wants to some parts be more detailed or something is missing there, your feedback is welcome.

Subversion 1.5.0 has been recently released (June the 19th) and I'm surprised with the tons of great stuff it brings. Some highlights:

• A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.
  Consider this scenario: Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to 'foo', and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file 'bar', and unversion the file 'foo' (if it had no uncommitted changes, Subversion would remove it entirely.) From Sally's point of view, her changes seem to be lost; the newly added 'bar' file has the older content, and the file 'foo' has been taken out of version control.
  In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn't send a whole new file during the update, but rather instructions to copy something that likely already exists in the working copy. So Sally's 'foo' file is copied to 'bar' (with local edits intact!).
  
• Merge tracking means Subversion keeps track of what changes have been merged where. This reduces the overhead involved in maintaining branches, and gives users a way to inquire what changes are merged — or are available to be merged — on different lines of development.
  Example (one of the improvements in place): Merging changes from (say) trunk to a branch no longer requires that you specify the revision range. Instead, each time you want to sync up with trunk, you can just do:
  

  
     $ cd BRANCH_WORKING_COPY
     $ svn merge URL_TO_TRUNK
  

  
  Subversion will figure out what changes from URL_TO_TRUNK have not yet been merged and pull in just those changes. When it's time to merge the branch back to trunk, do this:
  

  
     $ cd TRUNK_WORKING_COPY
     $ svn merge --reintegrate URL_TO_BRANCH
  

  
  
• Sparse checkouts (via new --depth option): Many users have very large trees of which they only want to checkout certain parts. In previous versions of Subversion, checkout -N was not really up to this task. Subversion 1.5 introduces the --depth option to the checkout, and other subcommands.
  
• Conflict resolution is now done interactively by the command-line client for the update/switch/merge subcommands.
  
• Relative URLs and @peg revisions for svn:externals.

Don't you think this is AMAZING? This means we almost got full/real MOVE support and that merging is taking the best ideas from DVCS systems (yes, we lack yet local commits).

To get up to speed with DVCS features I would also add pending commits feature although there are concerns and people seem to prefer it to be implemented upstream in bug tracking tools.

Well, I guess you already may have noticed I don't like current DVCS tools (at least the most popular), by a different set of (a little bit subjective, I know) set of reasons:

- Git: it's implemented in an unmanaged language (yeah SVN too, but at least the latter is cross-platform!).
- Bazar & Mercurial: they're implemented in a "too-managed" language (yeah sorry I dislike dynamically typed languages very much, especially for big developments that need to have a long life; yeah, refactorings are a pain with these ones, although I don't know the test coverage they may have...).

Maybe Git# (Mono SoC2008) is the answer? (I don't know the progress of this project.)

I was discussing about this yesterday with JP, and when I talked to him about this SVN 1.5.0 he said "too late!". Ermmm, what?, Gnome hasn't switched to DVCS yet so, why too late? Maybe because it's imminent? I don't know. Sincerely, there is much contradiction about how people approach migrations... Today I've been attending for almost an hour a meeting about Gnome Mobile, and one thing that was arised is the lack of flexibility and ease of use of the Gtk+ toolkit, as opposed to other toolkits. People were concerned about it and wanted to fix it, and nobody wanted to give up pushing Gtk+ just because it's old. Then, why doing this for Subversion? Subversion is very mature, and their devs have demonstrated to be worried about its lack of flexibility wrt the new distributed ways of work, so they are fixing it, they are *supporting* us. And however at Guadec here it seems everybody wants to push for the migration (but only taking care of doing the correct decision, i.e., select the 1 from the 3 we all know, but why not considering just to update to new SVN and wait a bit more to see where we go?

Well, now that I'm talking about Subversion, I'm going to talk you about a couple of features I worked on recently (and committed today), as my first ITO day, in the Subversion Addin of MonoDevelop: revert to revision, and revert changes from a revision. The mandatory screenshot (you get to this dialog when requesting the Log inside the Version Control contextual menu):


This reduces the need of having a console open when coding with the MonoDevelop IDE, which is a thing that many developers request.

Another feature I completed is the new pattern for searching in many files inside MonoDevelop: Current project (previously we only had "Whole solution", "Directories" and "Open files"):


Enjoy them! (Currently on SVN.)

I don't think it would be appropriate for PlanetSUSE, but if you want to have a look at the place where S.u.S.E, SuSE, openSUSE comes from, my other blog is a photo blog about the area: Nuernberg Photos.

You might win a prize (be warned though) if you can tell me what that is (one of it has a name, so don't be rude):

Dear Lazyweb,

Does anyone have suggestions on what to use for centralized storage at home? I have a lot of music/photos here piling up and would like to put them on some energy-efficient NAS box. Ideally it would have some sort of of built-in backup solution as well. A lot of the NAS-in-a-box solutions seem to have RAID 1, but that really only helps for HA. I am more concerned with never ever losing this stuff than having it available 24/7.

As I already wrote, there is support in YaST network module to configure IPv6 addresses (one or more), possibly mixed with IPv4:





But what is really new - support to configure apache2 server for IPv6 environment:

Setup on which addresses apache listen


Detail of virtual host (based on IP)


And test that it works:


This is in version yast2-http-server-2.17.2

After you have the domain from Godaddy it't time to change the default parking option in order to put your nameservers for domain. First you need to register your new nameservers with them and only after that to change the nameservers for your domain, otherwise you will see a nice "ERROR DETECTED" message. So, here is what you have to do:

Enter ns1 and its ip address click OK, and do the same step for ns2 with its ip address.

Now you are ready to put and to use your new registered nameservers for your domain.

That's all.

Сообственно уже с неделю работаю на 11 версии OpenSuse. + Быстро поставилось Yast не жрёт много оперативы Zypper работает реально быстрее — КДЕ 4 ещё сырой Много багов, приходиться обновляться раз в 3 дня wxPythona нет! Ужас

In order to give an answer about “Why this package will be installed and who needs it?” I have added a new Dialog in the QT single package selector:

Select one item (pattern, package) in the single selection frame, use the right mouse button and select “Show solver information”. A solverrun will be made for this item and the result will be shown with this dialog.

• Black arrow : This item will be required by….
• Green arrow: This item will be recommended by…
• Green boxes: This package is already installed
• Grey boxes: This package will be installed
• Blue boxes: Patterns

You can navigate through the tree via the overview frame:

After you have selected one item in the tree you can see more information about:

e.G. this item will install two further patterns due to the shown dependencies.

In order to decrease the complexity of the tree you can blind out:

• already installed packages
• recommended packages/patterns

So you will get a shrinked tree:

Technical Background:

This is a simple Qt Dialog widget which can be used in other programs too. ( Package libqdialogsolver1)

YaST uses this widget as a YaST plugin. So if this package is not available you will get a popup in single selection only.

Many people has been asking about the status of the debugger integration in MonoDevelop, so I thought it would be a good idea to post a quick status report.

The short answer is that we are working on it. The debugger integration work has started, and there is already support for breakpoints, stepping, call stack view, current frame selection, basic variable watch window, and attaching/detaching to/from running processes. All this is working in MonoDevelop from SVN (still with some stability issues).

And here are some big news: we are integrating not only MDB (the Mono debugger), but also GDB, and thanks to the debugger abstraction layer we built in MD, we'll be able to use the same GUI for both debuggers. Two debuggers for the price of one!

We are going to do a MonoDevelop release next week. However, this release will not include the debugger integration because it still depends on Mono and MDB from SVN and we would not be able to package it. If you want to try the debugger (beware, this is work in progress), you have to do the following:

• Get and build Mono from SVN.
• Get and build the Mono Debugger from SVN.
• Get MonoDevelop from SVN.
• At the MonoDevelop's top-level directory, run './configure --select'. Make sure the extras/MonoDevelop.Debugger.Mdb add-in is selected (and/or extras/MonoDevelop.Debugger.Gdb if you want GDB support).
• Build MonoDevelop.
  

If you only want to try GDB, you don't need Mono and MonoDebugger from SVN, getting latest MonoDevelop is enough.