Smalltalk › Squeak › Squeak - Dev

Monticello Workflow

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Jeff Gonis-2

Monticello Workflow

Hi Everyone,

So its time for my annual Monticello question to the squeak-dev list. This time I am trying to refresh my memory of how Monticello works and the workflow I should use for distributed development with it.

My basic setup is as follows: I have a personal repository in a directory on my personal computer and the person I am working with has the same. There is a "central" repository set up on a server as well. Ideally I would grab the latest changes from the "central" repository and spend some time working away, committing to my personal repository throughout the day, and my co-worker would be doing the same with their personal repository.

At some point I'll be satisfied with my changes and I'll want to upload them to the "central" repository. Based on my intuition I would first want to "merge" in the latest version from the "central" repository so that I deal with any conflicts. Ok, I can do this, it seems straightforward. Now having done that my package lists both my latest local version and the version I merged in from the "central" repository beside the package name.

I would think at this point that the correct move would be to save the package to my personal repository, and then Copy that version from my computer up to the "central" repository. Does this sound about right for enabling distributed development, and avoiding conflicts? One question I would ask is, that when I go to save to my personal repository after doing this, I get a warning telling me that the version in my personal repository may be newer than the version that I am trying to save. This doesn't seem right though, or at least I don't understand the reasoning behind this warning.

Anyway, if this is totally the wrong way to do distributed development, please let me know. If I am on the right track but confused about some critical details please let me know that too.

Thanks,
Jeff

Chris Muller-3

Re: Monticello Workflow

Yes.

On Fri, Aug 16, 2013 at 3:09 PM, Jeff Gonis <[hidden email]> wrote:

> Hi Everyone,
>
> So its time for my annual Monticello question to the squeak-dev list. This
> time I am trying to refresh my memory of how Monticello works and the
> workflow I should use for distributed development with it.
>
> My basic setup is as follows: I have a personal repository in a directory on
> my personal computer and the person I am working with has the same. There
> is a "central" repository set up on a server as well. Ideally I would grab
> the latest changes from the "central" repository and spend some time working
> away, committing to my personal repository throughout the day, and my
> co-worker would be doing the same with their personal repository.
>
> At some point I'll be satisfied with my changes and I'll want to upload them
> to the "central" repository. Based on my intuition I would first want to
> "merge" in the latest version from the "central" repository so that I deal
> with any conflicts. Ok, I can do this, it seems straightforward. Now having
> done that my package lists both my latest local version and the version I
> merged in from the "central" repository beside the package name.
>
> I would think at this point that the correct move would be to save the
> package to my personal repository, and then Copy that version from my
> computer up to the "central" repository. Does this sound about right for
> enabling distributed development, and avoiding conflicts? One question I
> would ask is, that when I go to save to my personal repository after doing
> this, I get a warning telling me that the version in my personal repository
> may be newer than the version that I am trying to save. This doesn't seem
> right though, or at least I don't understand the reasoning behind this
> warning.
>
> Anyway, if this is totally the wrong way to do distributed development,
> please let me know. If I am on the right track but confused about some
> critical details please let me know that too.
>
> Thanks,
> Jeff
>
>
>

Jeff Gonis-2

Re: Monticello Workflow

Hi Chris,

Given your answer I am going to assume that I am totally on the wrong track. I'll keep reading through the Monticello source code to work towards an understanding of the system, but in the meantime if you know of any resources you could point me towards that would help me understand how to set up monticello for distributed development I would greatly appreciate that.

Thanks for any and all help you can provide,
Jeff

Chris Muller-3

Re: Monticello Workflow

"Yes" was supposed to indicate I felt you are on the right track.

On Sun, Aug 18, 2013 at 1:41 PM, Jeff Gonis <[hidden email]> wrote:

> Hi Chris,
>
> Given your answer I am going to assume that I am totally on the wrong track.
> I'll keep reading through the Monticello source code to work towards an
> understanding of the system, but in the meantime if you know of any
> resources you could point me towards that would help me understand how to
> set up monticello for distributed development I would greatly appreciate
> that.
>
> Thanks for any and all help you can provide,
> Jeff
>
>
>

Levente Uzonyi-2

Re: Monticello Workflow

In reply to this post by Jeff Gonis-2

On Fri, 16 Aug 2013, Jeff Gonis wrote:

> Hi Everyone,
>
> So its time for my annual Monticello question to the squeak-dev list. This time I am trying to refresh my memory of how Monticello works and the workflow I should use for distributed development with it.
>
> My basic setup is as follows: I have a personal repository in a directory on my personal computer and the person I am working with has the same. There is a "central" repository set up on a server as well.
> Ideally I would grab the latest changes from the "central" repository and spend some time working away, committing to my personal repository throughout the day, and my co-worker would be doing the same with
> their personal repository.
>
> At some point I'll be satisfied with my changes and I'll want to upload them to the "central" repository. Based on my intuition I would first want to "merge" in the latest version from the "central"
> repository so that I deal with any conflicts. Ok, I can do this, it seems straightforward. Now having done that my package lists both my latest local version and the version I merged in from the "central"
> repository beside the package name.
>
> I would think at this point that the correct move would be to save the package to my personal repository, and then Copy that version from my computer up to the "central" repository. Does this sound about
> right for enabling distributed development, and avoiding conflicts? One question I would ask is, that when I go to save to my personal repository after doing this, I get a warning telling me that the version
> in my personal repository may be newer than the version that I am trying to save. This doesn't seem right though, or at least I don't understand the reasoning behind this warning.

What you describe here is the right way to use MC. The warning is a bug.
IIRC Bert wrote something about it a few months/years ago, but I can't
recall what the conclusion was.

Levente

>
> Anyway, if this is totally the wrong way to do distributed development, please let me know. If I am on the right track but confused about some critical details please let me know that too.
>
> Thanks,
> Jeff
>
>

Jeff Gonis-2

Re: Monticello Workflow

Hi Levente and Chris,

Thank you for the replies. Just as a final follow-up is this correct: Copying the merged mcz up to the remote server just sends the mcz as is to the server. This means that there is a chance that my co-worker has uploaded another change to the server that is not taken into account by my merged mcz. In this case I should merge those two mcz's and then save (or copy?) that to the server. I occasionally see commit messages to the list saying "merged changes", and I am assuming that this is what has happened in this case?

To summarize my question: If I am copying mcz's to the server, what is the correct way to deal with changes on the server that are more recent that the changes I am copying? Merge them on the server? Pull those changes down, merge on my own repository and then copy? Something else.

Thanks again for all your help. I think that nailing down this workflow for Monticello will really help me and perhaps I can contribute some documentation based on these emails.

Jeff

Levente Uzonyi-2

Re: Monticello Workflow

On Mon, 19 Aug 2013, Jeff Gonis wrote:

> Hi Levente and Chris,
>
> Thank you for the replies. Just as a final follow-up is this correct: Copying the merged mcz up to the remote server just sends the mcz as is to
> the server. This means that there is a chance that my co-worker has uploaded another change to the server that is not taken into account by my
> merged mcz. In this case I should merge those two mcz's and then save (or copy?) that to the server. I occasionally see commit messages to the
> list saying "merged changes", and I am assuming that this is what has happened in this case?

Yes.

>
> To summarize my question: If I am copying mcz's to the server, what is the correct way to deal with changes on the server that are more recent
> that the changes I am copying? Merge them on the server? Pull those changes down, merge on my own repository and then copy? Something else.

Merging always happens in your image. When you access a remote mcz from
the Monticello Browser, the file is copied to your package cache. When you
save something to a remote repository, a local copy will be added to your
package cache.
So even if you're seemingly merging on the server, both the inputs and
the output will be present on your machine too.

If you want to ensure that your changes are in the last version on the
server, then the best is to check if there's a newer version before and
after copying your changes to the server. But normally you just copy it,
and someone (either you, or someone else) will merge it later. Or you save
directly to the remote repository, and MC will notify you, if there's a
newer version available on the server.

Levente

>
> Thanks again for all your help. I think that nailing down this workflow for Monticello will really help me and perhaps I can contribute some
> documentation based on these emails.
>
> Jeff
>
>

Jeff Gonis-2

Re: Monticello Workflow

Levente, thank you very much for your explanations. Chris Muller thank you as well. What would be a good place for me to put some documentation based on this? The wiki? The help document in the image? Both? If no one has any preferences I'll start throwing something up on the wiki first, and if it is good enough you can let me know if it should be in-image as well.

Thanks again,
Jeff

On Mon, Aug 19, 2013 at 8:27 PM, Levente Uzonyi <[hidden email]> wrote:

On Mon, 19 Aug 2013, Jeff Gonis wrote:

Hi Levente and Chris,

Thank you for the replies. Just as a final follow-up is this correct: Copying the merged mcz up to the remote server just sends the mcz as is to
the server. This means that there is a chance that my co-worker has uploaded another change to the server that is not taken into account by my
merged mcz. In this case I should merge those two mcz's and then save (or copy?) that to the server. I occasionally see commit messages to the
list saying "merged changes", and I am assuming that this is what has happened in this case?

Yes.

To summarize my question: If I am copying mcz's to the server, what is the correct way to deal with changes on the server that are more recent
that the changes I am copying? Merge them on the server? Pull those changes down, merge on my own repository and then copy? Something else.

Merging always happens in your image. When you access a remote mcz from the Monticello Browser, the file is copied to your package cache. When you save something to a remote repository, a local copy will be added to your package cache.
So even if you're seemingly merging on the server, both the inputs and the output will be present on your machine too.

If you want to ensure that your changes are in the last version on the server, then the best is to check if there's a newer version before and after copying your changes to the server. But normally you just copy it, and someone (either you, or someone else) will merge it later. Or you save directly to the remote repository, and MC will notify you, if there's a newer version available on the server.

Levente

Thanks again for all your help. I think that nailing down this workflow for Monticello will really help me and perhaps I can contribute some
documentation based on these emails.

Jeff

Bert Freudenberg

Re: Monticello Workflow

In reply to this post by Levente Uzonyi-2

On 2013-08-19, at 03:14, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 16 Aug 2013, Jeff Gonis wrote:
>
>> One question I would ask is, that when I go to save to my personal repository after doing this, I get a warning telling me that the version
>> in my personal repository may be newer than the version that I am trying to save. This doesn't seem right though, or at least I don't understand the reasoning behind this warning.
>
> What you describe here is the right way to use MC. The warning is a bug. IIRC Bert wrote something about it a few months/years ago, but I can't recall what the conclusion was.

I just fixed it: Monticello-bf.563

When merging, it used to report versions in the repo with a higher version number than any of the merged versions. Now it looks at the highest-numbered merged version and only warns you if there is an even newer one found.

- Bert -