Hi Jan,

On Wed, Nov 14, 2007 at 10:36:17AM +0100, Jan Blunck wrote:

It seems that osc is changing the metadata format during update WITHOUT A WARNING. Since yesterday I get following errors:

Update: Kernel:Vanilla/kernel-source

the osc metadata of your working copy "." has the wrong version (0.98), should be 0.97 please do a fresh checkout

I'm sharing the repositories of my buildservice sync scripts with my workstation via NFS. It is totally insane that if I run an osc update on my workstation I have to update the CVS server the buildservice sync script is running on.

Annoyed, Jan

Yes, unfortunate. I trip over it myself, occasionally.

In the very beginning, when the working copy metadata format was still in development, the scheme "client version corresponds with the working copy format version" was sufficient, but that's a long time ago. This should have been decoupled, since metadata format hardly or never changes. It should rather be versioned itself.

But: nothing broke for the old clients. In fact, the metadata format didn't change at all.

A temporary workaround like echo 0.97 > .osc/_osclib_version && osc ... is safe.

Regarding a fix -- a look into osc/core.py check_store_version() shows that there was never a need to actually add upgrade logic:

if v != __version__: if v in ['0.2', '0.3', '0.4', '0.5', '0.6', '0.7', '0.8', '0.9', '0.95', '0.96', '0.97', '0.98']: # version is fine, no migration needed f = open(versionfile, 'w') f.write(__version__ + '\n') f.close() return

So far, the client simply stored the version number to denote that it has touched the working copy.

I'd suggest that we introduce a new version number x.y for the working copy, with x incremented for backwards incompatible changes and y incremented for smaller changes. We can set it to 1.0 then now.

Comments?

Peter