Nav-dev

nav-dev@lister.sikt.no

96 discussions

Rebasing with Mercurial
by Morten Brekkevold 07 Mai '08

07 Mai '08

Hi everyone, Since switching to Mercurial, I've heard about several developers running into scenarios where rebasing would be a nice feature. Some quick research on my part reveals that Mercural can do this, and that there is more than one way to do it (tm) ;-) First off, if you're unclear on what rebasing actually means, consider the following. You've cloned the default repository to work on a specific feature foo. You're committing changes to your foo branch, and then you feel the urge to pull the latest changes from the default branch. Your repo now looks like this: a---b---C---D (foo) \ ---o---p---q (default) Changeset q is now your repo tip, and your repo contains two heads. Mercurial will suggest that you merge these heads, thus creating this: a---b---C---D-----E (foo) \ / ---o---p---q (default) As you continue to develop in this fashion, you might end up with a history looking something like this, which looks kinda messy: a---b---C---D-----E---F---G---H---I---J (foo) \ / / / ---o---p---q-------r---s-------t (default) Since your foo branch really doesn't conflict with, or depend on anything going on in the default branch, you'd much rather have your history look like this: a---b---o---p---q---r---s---t---C---D---F---G---I foo) The previous graph shows your local foo changes rebased on top of the latest changeset from the default branch. Now you (presumably) know what rebasing means. Now, on to solutions: How to do it with MQ ==================== Mercurial Queues lets you maintain your changes as a patch queue, and also allows you to arbitrarily reorder your patches. Your named patches are stored in .hg/patches/ and can be applied and unapplied to your tree using the hg qpush and qpop commands. Your applied patches will look like regular changesets in your history, but they have special tags that mark them as the property of MQ. When you pop and push these patches, you're actually manipulating the history of your local repository. For more information about Mercurial Queues, please refer to http://hgbook.red-bean.com/hgbookch12.html . Using the above scenario: a---b---C---D (foo) \ ---o---p---q (default) C and D are two MQ changesets in your repository, and Mercurial pull has just suggested that you perform a merge. No way, you say, and do a "hg qpop -a", popping all your MQ changesets off the history, and then "hg up" to update your working copy to the new tip (revision q): a---b---o---p---q (foo) Then, you do "hg qpush -a" to push all your patches back on to the history as MQ changesets, thus: a---b---o---p---q---C---D (foo) As for the log messages of MQ changesets, we found that MQ will use any plaintext you insert at the beginning of the patch files stored in .hg/patches. To make sure an updated text appears in the log message, the patch must be popped, the text edited, and the patch pushed again. When you are ready to turn an applied MQ changeset/patch into a regular changeset (e.g. when you want to push it to another repo), you use "hg qdel -r C" and "hg qdel -r D", referring to the above scenario. How to do it with transplant ============================ The transplant extension can specifically be used to rebase changesets. In the same scenario as above, you have just pulled the latest changes from default: a---b---C---D (foo) \ ---o---p---q (default) So to rebase your C and D changesets you first need to update your working copy to the new tip (or q, if you will): hg up -C tip Then take the branch that revision D belongs to and rebase it onto the current working copy parent (q): hg transplant -b D The only catch is that your repo now looks like this: a---b---o---p---q---c---d (default) \ C---D (foo) c and d are copies of C and D. The capital C and capital D are still in your history. This is where "hg strip" comes in; this command can strip changesets from your history. With the above repo, you would want to strip the branch that begins with revision C, thus: hg strip C Which means you are now left with (don't forget hg update): a---b---o---p---q---c---d (foo) Warnings ======== Be warned that I am unsure how the transplant/strip operation will work if you are using named branches. With these scenarios, you are munging your local history a lot, and you should beware not to do this with branches/repos you are sharing with others. Things will start to get confusing when changesets that have been pulled by others (or pushed somewhere by you) are disappearing from your repo. -- mvh Morten Brekkevold UNINETT

1 0

Commit log policy
by Morten Brekkevold 10 Apr '08

10 Apr '08

As discussed internally during our switch to Mercurial, we should have a stated policy on how to write log messages when committing our work to the repositories. I've always found the Subversion dev team's guidelines on log messages to be a very useful example. I would like to submit to the rest of the devs the following as a template for what our policy should be like: http://subversion.tigris.org/hacking.html#log-messages Mercurial log listings emphasize the first log line of every changeset as a summary of the changes, as does the abovementioned guideline. I'd say this is the single most important thing to get right. You will not need to look far back in the NAV changelog to see some really bad examples of log messages, which were common among some of the earlier developers (The guilty shall remain anonymous. Until you actually inspect the logs). I'd like comments from current devs on the abovementioned guidelines. Should we blatantly copy them and replace all mention of Subversion with NAV, or should we make some appropriate changes? -- mvh Morten Brekkevold UNINETT

1 0

pst fryser
by Knut-Helge Vindheim 08 Apr '08

08 Apr '08

Periodevis så går det veldig tregt, det ser ut som om pst fryser og at data i fra databsen går veldig tregt. Mvh -- Knut-Helge Vindheim NTNU, IT-Avdelingen / Nett Tlf 73590011

2 1

innsamling av dhcp-leases i cricket på pst ser ut til å ha stoppet.
by Knut-Helge Vindheim 07 Apr '08

07 Apr '08

som subjektet seier+ at jeg ikke ser vlan som blant annet 191. Mvh -- Knut-Helge Vindheim NTNU, IT-Avdelingen / Nett Tlf 73590011

1 0

Version control migration
by Morten Brekkevold 03 Apr '08

03 Apr '08

As stated in this year's development project, we will migrate NAV's version control system to a distributed version control system. After playing around with Bazaar-NG (bzr) and Mercurial (hg) for a while, we've finally chosen Mercurial for the job. Please see http://www.selenic.com/mercurial/ for more information on Mercurial. Mind you, this choice is very much based on gut feeling and prior SCM usage patterns. There is little that distinguishes bzr and hg in terms of functionality, which has made testing a typical NAV release cycle with each tool an important part of the decision. Where and how ============= Although Mercurial supports named branches, I've elected to convert each Subversion branch into a separate Mercurial repository. These repositories can be found at the following URL: http://metanav.uninett.no/hg/ The Subversion trunk can be found as the repository named "default". Each repository actually uses one named branch each, which will make it easier to identify where changes came from when merges occur. This won't be a hard requirement though, but it is good to know when cloning and working with one of the branch repositories. Push access to the repositories will be granted to the developers currently employed by UNINETT (please come by my office to get a username/password). Other developers are encouraged to publish their own repositories, and ask us to pull from these when changes are ready to be merged with the official repositories (Or send us your Mercurial bundles or regular patch files). Although the new distributed model enables each developer to work "offline" much of the time, I strongly urge you to regularly push your changes to a an offical feature branch (if you have one, that is). Quirks ====== There are some quirks in the conversion, mostly due to the different world view of svn and hg. First off, we've lost some of our tags, more specifically, all the 3.0.0_alpha* tags. These weren't very important anyway, so they will probably not be missed by anyone. These tags were not understood by the conversion tool because of the way they were created (in the old days, when we hadn't familiarized ourselves properly with Subversion yet). The second quirk is a similar problem. Each release of NAV contains the file named VERSION, which contains the NAV version number. For each release, I checked out a working copy of the current release branch (e.g. 3.3.x), changed the contents of VERSION (e.g. to 3.3.1) and copied my working copy to the subversion tags directory. The resulting revision is a copy of branches/3.3.x to tags/3.3.1, with a small change to the VERSION file. Since tags don't work like that at all in the modern distributed systems, the conversion tool couldn't pick up the change that happened to the VERSION file as it was tagged. The end result is that the contents of the VERSION file will not be correct in the version tags that are present in the Mercurial repositories. The only way this could have been mapped to a DVCS was if each release version was made into a branch of its own. I could have elected to set tags on all changesets to map them to the corresponding Subversion revision number; this would have made it easier to identify changesets referred to by changeset comments, old SourceForge bug reports and mailing list messages. On the other hand, I felt this would clutter opp the tag listings for the repositories, and make tags less useful (>4000 tags!) I do, however, have a "shamap" file from the conversion tool, which maps each Subversion revision number to a Mercurial changeset SHA id. I would like some suggestions on what to do with this file, since it could be useful. Should I publish it on the web, or commit it to the default repository? -- mvh Morten Brekkevold UNINETT

1 0

Mailing lists will be moved
by morten.brekkevold＠uninett.no 12 Mar '08

12 Mar '08

Hi everyone, This is just a notification that the nav-users, nav-dev and nav-commit mailing lists will be moved to a different address within the next couple of weeks. The lists are currently hosted by the Norwegian University of Science and Technology (NTNU). They will soon be migrating to new mailing list software, which will be accessible only internally to NTNU employees and students. Because of this, we will begin hosting the NAV mailing lists here at UNINETT. The subscriber list and archives should be migrated by the end of the next two weeks. A new announcement will be made then. -- mvh Morten Brekkevold UNINETT

2 1

metanav improvements
by vidar.faltinsen＠uninett.no 01 Okt '07

01 Okt '07

Hi all, I had a look at metanav today and did several improvements here and around. To skip details, the two majo things are; 1. I have added a "config file" and "log file" section in "backendprocesses". There may be errors - please check. 2. I have started on the task of making a user guide to NAV. This is done be restructuring "navconfiguration" page. Here I have included a "Using the NAV tools" sections where each tool from the toolbox is listed with its appropriate NAV 3.3 icon(!) and a link to a new wiki page for the tool. Some of the tools already had a wiki page in place, for others I have made one, or at least started. Hopefully more people will contribute and we will get this job done before christmas. I will discuss this and more with Morten tomorrow. Morten; your archive with the good old report.conf explaination is wanted. - Vidar

1 2

Test, please ignore
by morten.brekkevold＠uninett.no 09 Jul '07

09 Jul '07

We've had reports that e-mails are not coming through to the lists. This is just a test e-mail to check. -- mvh Morten Brekkevold UNINETT

1 0

Missing import?
by morten.brekkevold＠uninett.no 15 Mar '07

15 Mar '07

Dag-Erling Sm?rgrav wrote, On 14-03-2007 13:16: > AttributeError: 'module' object has no attribute 'auth' > > The following one-line fix seems to solve the problem for me: > > --- subsystem/webFront/lib/nav/web/auth.py.orig Tue Mar 13 11:59:25 2007 > +++ subsystem/webFront/lib/nav/web/auth.py Wed Mar 14 12:09:35 2007 [...] > However, I wouldn't expect a bug like this to slip into a release, so > I have to wonder if something else is wrong - a missing PythonOption > perhaps? Unfortunately, I'm not very familiar with Python. Actually, there is some historical weirdness with importing submodules under mod_python. I think it has been fixed in newer versions, but the bugs are still present in Debian/sarge (mod_python 3.1.3). To try working around these import problems, nav does some rather odd importing of modules from a lower point in the package hierarchy. The nav module itself imports the nav.auth module into its own namespace (as 'auth'). Although nav.web.auth (the one you've patched above) doesn't explicitly import nav.auth, it imports nav, which has the symbol 'auth' in its namespace. That's why this (normally) works. So why it suddenly doesn't work at your end I can't be sure of, because there have been no changes to this code that I'm aware of. A situation where it might fail, though, is if the nav module failed to import the nav.auth module for some reason. I'm going to take a closer look at this import circus when Debian/etch is released as the next stable version, but your patch might solve the problem at hand, as long as it doesn't break anything for anyone else (thanks!). -- mvh Morten Brekkevold UNINETT

1 0

Memory leaks in getDeviceData
by morten.brekkevold＠uninett.no 09 Mar '07

09 Mar '07

Some of you have noticed problems with getDeviceData running out of Java heap memory, and then getting out of sync with the PostgreSQL database driver - it ends up doing strange updates to the database. The issue is described in this bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1675508&group_id=1… For the technically inclined, here's a complete summary: I've traced the problem back to the Java SNMP package provided by drexel.edu. This package is used by the getDeviceData and getBoksMacs NAV processes to perform SNMP queries. The problem is an infinite loop, in which the library sends the same GETNEXT request over and over, and growing a list of SNMP responses until the heap is full. In a getDeviceData context, this problem can occur during OID testing of a device (This is when gDD attempts to figure which SNMP OIDs a new device supports). When the OID tester attempts to query an OID using GETNEXT requests, it uses the Java SNMP package's method for snmpwalking a MIB tree (retrieveMIBTable). If the OID is outside the MIB view of an SNMPv2c device, the device will respond with an SNMPv2 endOfMibView exception. Ufortunately, the retrieveMIBTable method of drexel's Java SNMP package treats this exception as just another value and adds it to the list of responses. Since the exception's object identifier is the same as the one used in the GETNEXT request, the method will continue to issue GETNEXT requests for the same OID until it no longer receives any response, or until it runs out of memory, whichever comes first. I've written two different patches to fix the problem in the Java SNMP Package, and I have submitted these patches to the upstream authors. The simplest patch is available at the aforementioned bug report page, for those who want to apply it themselves. I'm also planning to write a workaround for NAV. It is quite unnecessary for the NAV OID tester to walk entire SNMP tables just to test OID compatibility. Issuing a single GETNEXT request should be enough to determine whether the OID is supported or not. By doing this, the OID tester can avoid using the retrieveMIBTable method of the drexel library entirely. -- mvh Morten Brekkevold UNINETT >From des at des.no Wed Mar 14 13:16:52 2007 From: des at des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed Mar 14 13:17:02 2007 Subject: [Nav-dev] Missing import? Message-ID: <86wt1k3tqj.fsf(a)dwp.des.no> NAV 3.2.1 "out of the box" on FreeBSD 6.2-RELEASE, after logging in as admin / admin, clicking on any link on the front page results in the following: Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/local/nav/lib/python/nav/web/__init__.py", line 62, in headerparserhandler nav.web.auth.authenticate(req) File "/usr/local/nav/lib/python/nav/web/auth.py", line 102, in authenticate if not checkAuthorization(user, req.unparsed_uri): File "/usr/local/nav/lib/python/nav/web/auth.py", line 52, in checkAuthorization return nav.auth.hasPrivilege(user, 'web_access', uri) AttributeError: 'module' object has no attribute 'auth' The following one-line fix seems to solve the problem for me: --- subsystem/webFront/lib/nav/web/auth.py.orig Tue Mar 13 11:59:25 2007 +++ subsystem/webFront/lib/nav/web/auth.py Wed Mar 14 12:09:35 2007 @@ -30,6 +30,7 @@ import nav import logging +from nav import auth from nav import db from nav.db import navprofiles from nav.web.preferences import Preferences, Link However, I wouldn't expect a bug like this to slip into a release, so I have to wonder if something else is wrong - a missing PythonOption perhaps? Unfortunately, I'm not very familiar with Python. DES -- Dag-Erling Sm?rgrav - des(a)des.no

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Nav-dev