[opensuse-buildservice] OSC changing the metadata format on update
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 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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 -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Wed, Nov 14, Dr. Peter Poeml wrote:
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.
From a brief look at the metadata I realized that it is all written in XML. Why don't we make use of that fact? Creating a schema that is backwards and forward compatible?
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Nov 15, 2007 at 04:15:32PM +0100, Jan Blunck wrote:
From a brief look at the metadata I realized that it is all written in XML. Why don't we make use of that fact? Creating a schema that is backwards and forward compatible?
I think we do that already as far as possible. But there _can_ be changes which would not be covered. First, osc basically saves metadata as it looks like when it comes from the api. Thus, if it is changed upstreams, osc needs to notice. Second, there can be other metadata in .osc, which is not xml. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
participants (2)
-
Dr. Peter Poeml -
Jan Blunck