[vwnc] Store - odd versions of renamed packages

Hello,

We recently started new project in VW 7.6 (because VW 7.7 is
still in development) and found an odity in Store's behaviour.

When browsing packages (Published Items) in VW 7.4, only
versions with the same name are regarded as parents of a
package (DBRecord class >> allVersionsWithName: aString).

In VW7.6 all traces are regarded as parents regardless what
their name is (Pundle class >> allVersionsWithName: aString).
This causes havoc because suddenly the user sees things like:

(1.2; someone) Ready To Merge "Old Name"
(1.1; someone) Ready To Merge "Old Name"
(1.2; someone) Ready To Merge "New Name"
(1.1; someone) Merged "New Name"
(1.0; someone) Merged "Old Name"

The scenario:
  1. First there was a package named "Old Name (1.0)".
  2. This package was modified, renamed and published as "New Name (1.1)".
  3. Both packages evolved over time and were used simultaneously
     as two distinct entities in VW 7.4 (correct or at least
     expected behavior for us).
  4. But are seen as several versions of one package in VW 7.6.

I checked VW 7.7 as well and it works only by coincidence, because

Pundle class >> allVersionsWithName: aName notIn: aSet lessThanTimeStamp: aTimeStamp

is only called with aTimeStamp == nil in which case fallbacks to
VW 7.4 behaviour.

Questions:
  1. What was the motivation for the new behaviour?
  1. What is the motivation for VW 7.7 changes when it's never called?
  1. Is the situation described above expected behaviour or a bug?


Thanks in advance,

Ladislav Lenart

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The motivation for the new behaviour is that if you rename a package or bundle, you do not lose the version history prior to the rename.

In 7.7 it is called, but it will ignore versions under the old name which are more recent than the old name. This is helpful in the case where you haven't really renamed the package, but have rather forked it into being two independent packages.

The 7.6 behaviour is expected, but with the bug as described, corrected in 7.7. If you don't want this behaviour, then when you do the rename, unreconcile the package before publishing. Or, if it's already been done, you can go into the database and set the trace field to 0 on the first renamed version. The tools don't support this, but it can be done through regular database tools.

At 06:51 AM 2009-10-22, Ladislav Lenart wrote:

Hello,

We recently started new project in VW 7.6 (because VW 7.7 is
still in development) and found an odity in Store's behaviour.

When browsing packages (Published Items) in VW 7.4, only
versions with the same name are regarded as parents of a
package (DBRecord class >> allVersionsWithName: aString).

In VW7.6 all traces are regarded as parents regardless what
their name is (Pundle class >> allVersionsWithName: aString).
This causes havoc because suddenly the user sees things like:

(1.2; someone)  Ready To Merge  "Old Name"
(1.1; someone)  Ready To Merge  "Old Name"
(1.2; someone)  Ready To Merge  "New Name"
(1.1; someone)  Merged           "New Name"
(1.0; someone)  Merged           "Old Name"

The scenario:
  1. First there was a package named "Old Name (1.0)".
  2. This package was modified, renamed and published as "New Name (1.1)".
  3. Both packages evolved over time and were used simultaneously
     as two distinct entities in VW 7.4 (correct or at least
     expected behavior for us).
  4. But are seen as several versions of one package in VW 7.6.

I checked VW 7.7 as well and it works only by coincidence, because

Pundle class >> allVersionsWithName: aName notIn: aSet lessThanTimeStamp: aTimeStamp

is only called with aTimeStamp == nil in which case fallbacks to
VW 7.4 behaviour.

Questions:
  1. What was the motivation for the new behaviour?
  1. What is the motivation for VW 7.7 changes when it's never called?
  1. Is the situation described above expected behaviour or a bug?


Thanks in advance,

Ladislav Lenart

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc