Smalltalk › Cincom › VisualWorks

[Glorp Replicator] Parent expected but not found?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Boris Popov, DeepCove Labs (SNN)

[Glorp Replicator] Parent expected but not found?

My 'suppression' quest-of-the-day continues,

Quick question, it seems that pundle versions that were replicated
non-recursively raise a little warning on load that says 'Parent expected
but not found'. How would we go about disabling it?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

smime.p7s (4K) Download Attachment

Michael Lucas-Smith

Local store and replication

I hear a lot of people use a local store and then replicate to a shared store. At SWS we don't do that - we just put up with the slow communications to our shared store.

What do people do when they need to merge?

Cheers,
Michael

Boris Popov, DeepCove Labs (SNN)

RE: Local store and replication

More often than not we just use diff files that we file out from one side of
the merge and file into the other using the Change List, but that only works
nicely because we're all usually working on different parts of the
application so there's rarely any major changes that need manual resolution.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Michael Lucas-Smith [mailto:[hidden email]]

Sent: Wednesday, May 03, 2006 3:35 PM
To: [hidden email]; Alan Knight
Subject: Local store and replication

I hear a lot of people use a local store and then replicate to a shared
store. At SWS we don't do that - we just put up with the slow communications
to our shared store.

What do people do when they need to merge?

Cheers,
Michael

smime.p7s (4K) Download Attachment

Joerg Beekmann, DeepCove Labs (YVR)

RE: Local store and replication

In reply to this post by Michael Lucas-Smith

As Boris note we often go the "old fashioned way" and use file outs and
change sets. However the decision to merge this way is orthogonal to the
whether or not we use a local store. Our remote contractors have local
stores to which they replicate, they then develop away, perhaps
publishing perhaps not it doesn't really matter to use. Ultimately they
replicate a version back to use. We can then merge the version they
replicated back using any strategy we want.

If the merge is complex and using a change list does not seem
appropriate we generally compare changes between the two bundles and
then using the Store merge tool on each package that has changed. This
provides greater control than simply merging two large bundles and is
much faster.

> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: Wednesday, May 03, 2006 3:47 PM
> To: Michael Lucas-Smith; [hidden email]; Alan Knight
> Subject: RE: Local store and replication
>
> More often than not we just use diff files that we file out from one
side

> of
> the merge and file into the other using the Change List, but that only
> works
> nicely because we're all usually working on different parts of the
> application so there's rarely any major changes that need manual
> resolution.
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
> -----Original Message-----
> From: Michael Lucas-Smith [mailto:michael.lucas-
> [hidden email]]
>
> Sent: Wednesday, May 03, 2006 3:35 PM
> To: [hidden email]; Alan Knight
> Subject: Local store and replication
>
> I hear a lot of people use a local store and then replicate to a

shared
> store. At SWS we don't do that - we just put up with the slow
> communications
> to our shared store.
>
> What do people do when they need to merge?
>
> Cheers,
> Michael

Charles A. Monteiro-2

Re: Local store and replication

In reply to this post by Michael Lucas-Smith

we are a small shop however we often have overlaps with regards to what
code is being played on. We work on our tasks locally and do use Store
locally as oppossed to simply relying on saving one's image. We also have
backup processes for the local stores. Only when a specific set of tasks
are accomplished are packages published with an "integration ready"
blessing to the team repository. We then use the merge tool and actually
do a merge, which

We don't replicate to the team but I was considering using replication to
re-sync our local repositories with the latest in team i.e. from team to
local. Have not tried it yet since for one our team repository is an
Interbase repository and it at least used to be the case that we could not
use the newer glorp based replicator with Interbase. BTW, no need to
support glorp replication for Interbase on my account we will be moving
the team repository to Postgres in the near future.

-Charles

On Wed, 03 May 2006 18:34:58 -0400, Michael Lucas-Smith
<[hidden email]> wrote:

> I hear a lot of people use a local store and then replicate to a shared
> store. At SWS we don't do that - we just put up with the slow
> communications to our shared store.
>
> What do people do when they need to merge?
>
> Cheers,
> Michael

--
Charles A. Monteiro

Alan Knight-2

Re: [Glorp Replicator] Parent expected but not found?

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Well, it's true that they're not found, since you didn't replicate them.

I would think the options are
a) get rid of them, set the trace field to zero
b) fake them, set the trace field to something else, e.g. if you replicated version "2.0", you could set its parent to be version "1.0", instead of version "2.0 beta 993".
or I guess
c) comment out the warning

The easiest way to change the trace would be to open a Store Workspace and read in the instance and modify it as you wished. Or just an ad hoc sql and do likewise.

At 05:43 PM 03/05/2006, Boris Popov wrote:

>My 'suppression' quest-of-the-day continues,
>
>Quick question, it seems that pundle versions that were replicated
>non-recursively raise a little warning on load that says 'Parent expected
>but not found'. How would we go about disabling it?
>
>Cheers!
>
>-Boris
>
>--
>+1.604.689.0322
>DeepCove Labs Ltd.
>4th floor 595 Howe Street
>Vancouver, Canada V6C 2T5
>
>[hidden email]
>
>CONFIDENTIALITY NOTICE
>
>This email is intended only for the persons named in the message
>header. Unless otherwise indicated, it contains information that is
>private and confidential. If you have received it in error, please
>notify the sender and delete the entire message including any
>attachments.
>
>Thank you.
>

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Boris Popov, DeepCove Labs (SNN)

RE: [Glorp Replicator] Parent expected but not found?

In reply to this post by Boris Popov, DeepCove Labs (SNN)

It appears that A and B won't really work on packages published as binary,
as they contain trace information in the properties within them, so zero'ing
it out in the db has no effect on the load. I may just suppress the warning
with a handler someplace, but its something that people should be aware of.

Thanks, Alan.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Alan Knight [mailto:[hidden email]]
Sent: Thursday, May 04, 2006 12:04 PM
To: Boris Popov; [hidden email]
Subject: Re: [Glorp Replicator] Parent expected but not found?

Well, it's true that they're not found, since you didn't replicate them.

I would think the options are
a) get rid of them, set the trace field to zero
b) fake them, set the trace field to something else, e.g. if you
replicated version "2.0", you could set its parent to be version "1.0",
instead of version "2.0 beta 993".
or I guess
c) comment out the warning

The easiest way to change the trace would be to open a Store Workspace and
read in the instance and modify it as you wished. Or just an ad hoc sql and
do likewise.

At 05:43 PM 03/05/2006, Boris Popov wrote:

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
Niall Ross

smime.p7s (4K) Download Attachment

Alan Knight-2

RE: [Glorp Replicator] Parent expected but not found?

Ah, yes. If anything is published binary, then the trace is stored in properties and BOSSed in as part of the parcel. Changing that seems non-trivial, so it's difficult to do anything. The warning is meaningless, because it gets the trace as it decodes the parcel, but the created package then gets the proper value from the database.

At 07:37 PM 04/05/2006, Boris Popov wrote:

>It appears that A and B won't really work on packages published as binary,
>as they contain trace information in the properties within them, so zero'ing
>it out in the db has no effect on the load. I may just suppress the warning
>with a handler someplace, but its something that people should be aware of.
>
>Thanks, Alan.
>
>-Boris
>
>--
>+1.604.689.0322
>DeepCove Labs Ltd.
>4th floor 595 Howe Street
>Vancouver, Canada V6C 2T5
>
>[hidden email]
>
>CONFIDENTIALITY NOTICE
>
>This email is intended only for the persons named in the message
>header. Unless otherwise indicated, it contains information that is
>private and confidential. If you have received it in error, please
>notify the sender and delete the entire message including any
>attachments.
>
>Thank you.
>
>-----Original Message-----
>From: Alan Knight [mailto:[hidden email]]
>Sent: Thursday, May 04, 2006 12:04 PM
>To: Boris Popov; [hidden email]
>Subject: Re: [Glorp Replicator] Parent expected but not found?
>
>Well, it's true that they're not found, since you didn't replicate them.
>
>I would think the options are
> a) get rid of them, set the trace field to zero
> b) fake them, set the trace field to something else, e.g. if you
>replicated version "2.0", you could set its parent to be version "1.0",
>instead of version "2.0 beta 993".
>or I guess
> c) comment out the warning
>
>The easiest way to change the trace would be to open a Store Workspace and
>read in the instance and modify it as you wished. Or just an ad hoc sql and
>do likewise.
>
>At 05:43 PM 03/05/2006, Boris Popov wrote:
>>My 'suppression' quest-of-the-day continues,
>>
>>Quick question, it seems that pundle versions that were replicated
>>non-recursively raise a little warning on load that says 'Parent expected
>>but not found'. How would we go about disabling it?
>>
>>Cheers!
>>
>>-Boris
>>
>>--
>>+1.604.689.0322
>>DeepCove Labs Ltd.
>>4th floor 595 Howe Street
>>Vancouver, Canada V6C 2T5
>>
>>[hidden email]
>>
>>CONFIDENTIALITY NOTICE
>>
>>This email is intended only for the persons named in the message
>>header. Unless otherwise indicated, it contains information that is
>>private and confidential. If you have received it in error, please
>>notify the sender and delete the entire message including any
>>attachments.
>>
>>Thank you.
>>
>
>--
>Alan Knight [|], Cincom Smalltalk Development
>[hidden email]
>[hidden email]
>http://www.cincom.com/smalltalk
>
>"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
>Niall Ross
>
>

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Boris Popov, DeepCove Labs (SNN)

RE: [Glorp Replicator] Parent expected but not found?

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Yea, my thoughts exactly. I ended up overriding PundleModel>>parentRecord to
remove the warning altogether. Ideally these would be (optionally) logged
into a separate window detailing the results of any particular load from
StORE, but not seeing them is step in the right direction for us. It's not
like anyone's ever going to say 'no' in the confirmation dialog :)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Alan Knight [mailto:[hidden email]]
Sent: Friday, May 05, 2006 8:45 AM
To: Boris Popov; [hidden email]
Subject: RE: [Glorp Replicator] Parent expected but not found?

Ah, yes. If anything is published binary, then the trace is stored in
properties and BOSSed in as part of the parcel. Changing that seems
non-trivial, so it's difficult to do anything. The warning is meaningless,
because it gets the trace as it decodes the parcel, but the created package
then gets the proper value from the database.

At 07:37 PM 04/05/2006, Boris Popov wrote:
>It appears that A and B won't really work on packages published as binary,
>as they contain trace information in the properties within them, so
zero'ing

>it out in the db has no effect on the load. I may just suppress the warning
>with a handler someplace, but its something that people should be aware of.
>
>Thanks, Alan.
>
>-Boris
>
>--
>+1.604.689.0322
>DeepCove Labs Ltd.
>4th floor 595 Howe Street
>Vancouver, Canada V6C 2T5
>
>[hidden email]
>
>CONFIDENTIALITY NOTICE
>
>This email is intended only for the persons named in the message
>header. Unless otherwise indicated, it contains information that is
>private and confidential. If you have received it in error, please
>notify the sender and delete the entire message including any
>attachments.
>
>Thank you.
>
>-----Original Message-----
>From: Alan Knight [mailto:[hidden email]]
>Sent: Thursday, May 04, 2006 12:04 PM
>To: Boris Popov; [hidden email]
>Subject: Re: [Glorp Replicator] Parent expected but not found?
>
>Well, it's true that they're not found, since you didn't replicate them.
>
>I would think the options are
> a) get rid of them, set the trace field to zero
> b) fake them, set the trace field to something else, e.g. if you
>replicated version "2.0", you could set its parent to be version "1.0",
>instead of version "2.0 beta 993".
>or I guess
> c) comment out the warning
>
>The easiest way to change the trace would be to open a Store Workspace and
>read in the instance and modify it as you wished. Or just an ad hoc sql and
>do likewise.
>
>At 05:43 PM 03/05/2006, Boris Popov wrote:
>>My 'suppression' quest-of-the-day continues,
>>
>>Quick question, it seems that pundle versions that were replicated
>>non-recursively raise a little warning on load that says 'Parent expected
>>but not found'. How would we go about disabling it?
>>
>>Cheers!
>>
>>-Boris
>>
>>--
>>+1.604.689.0322
>>DeepCove Labs Ltd.
>>4th floor 595 Howe Street
>>Vancouver, Canada V6C 2T5
>>
>>[hidden email]
>>
>>CONFIDENTIALITY NOTICE
>>
>>This email is intended only for the persons named in the message
>>header. Unless otherwise indicated, it contains information that is
>>private and confidential. If you have received it in error, please
>>notify the sender and delete the entire message including any
>>attachments.
>>
>>Thank you.
>>
>
>--
>Alan Knight [|], Cincom Smalltalk Development
>[hidden email]
>[hidden email]
>http://www.cincom.com/smalltalk
>
>"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
>Niall Ross
>
>

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
Niall Ross

smime.p7s (4K) Download Attachment