On 13-Aug-08, at 4:26 PM, Avi Bryant wrote:

1. For your project, create a separate file repository for each

developer. So, Lukas, if you, Colin and I were all collaborating on something, we would have lr.mcr, avi.mcr, and cwp.mcr. 2. Set up a script which rsyncs these three files to a shared location. Each developer should have this script set up to *upload* their own mcr and to *download* everyone else's. 3. Commit to your own repository (I would commit to avi.mcr), and then run the script. Or, have a cron job which runs it every few minutes.

Since the project has all three repos added, everyone's versions should show up together in the UI. Since each developer is only modifying his own file, there shouldn't be any conflicts at the file level. Since the .mcr files are always only appended to, rsync should be able to update them quite efficiently (right?). And although there would be some duplication (each developer's repo would contain its own copy of most of the method versions), it would be O(developers) not O(versions) as MC1 is.

I like it!

AFAICT, the only hitch is that the current version of MC2 will always commit to all repositories in the project. Clearly there are all sorts of situations where that's not the right behavior. So far I've just punted on that for lack of specific use-cases. So to make this work, we just need to make it possible to configure repositories as read-only.

I'll implement that and we can try it.

Colin

On Wed, Aug 13, 2008 at 11:16 PM, Lukas Renggli renggli@gmail.com wrote:

...

Here's a strategy that I think would work to allow networked collaboration with MC2 in its current state. Colin, let me know if I'm making any faulty assumptions here or misremembering how MC2 works.

Ok, that makes sense for a company. What about projects like Seaside or OB where there are numerous developers that frequently change?

Managing the client side of that is easy: the image needs to know to look for new .mcr files in a certain directory and add them automatically as read-only repositories. The rsync script needs to look for these on the server and download them automatically.

As for managing the server, well, you could certainly add a unix account for each developer and set the permissions on the files appropriately so that they could only write to their own .mcr. The one thing this doesn't account for at all is anonymous commits...

A related question is if there is anything in place that prevents .mcr files from corruption when are accessed concurrently. I imagine that you could keep the repository files on a shared drive somewhere.

I think this should basically work, as long as two people aren't committing at precisely the same time. Even if they do, it might still work, I just don't remember if it's guaranteed :)

Avi

On Wed, Aug 13, 2008 at 11:39 PM, Avi Bryant avi@dabbledb.com wrote:

...

Ok, that makes sense for a company. What about projects like Seaside or OB where there are numerous developers that frequently change?

Managing the client side of that is easy: the image needs to know to look for new .mcr files in a certain directory and add them automatically as read-only repositories. The rsync script needs to look for these on the server and download them automatically.

To reactivate an old thread - getdropbox.com, which just came out of private beta, strikes me as perfect for this kind of shared, synced directory. We're also considering using it for MC1 repositories, but it would be much more storage and bandwidth efficient to use it with MC2.

Avi

2008/8/14 Norbert Hartl norbert@hartl.name:

On Wed, 2008-08-13 at 16:26 -0700, Avi Bryant wrote:

...

On Wed, Aug 13, 2008 at 1:29 AM, Lukas Renggli renggli@gmail.com wrote:

...

I am would like to see some documentation on how to migrate from the old Monticello. Also I am eagerly awaiting the network repositories.

Here's a strategy that I think would work to allow networked collaboration with MC2 in its current state. Colin, let me know if I'm making any faulty assumptions here or misremembering how MC2 works.

1. For your project, create a separate file repository for each

developer. So, Lukas, if you, Colin and I were all collaborating on something, we would have lr.mcr, avi.mcr, and cwp.mcr. 2. Set up a script which rsyncs these three files to a shared location. Each developer should have this script set up to *upload* their own mcr and to *download* everyone else's. 3. Commit to your own repository (I would commit to avi.mcr), and then run the script. Or, have a cron job which runs it every few minutes.

Since the project has all three repos added, everyone's versions should show up together in the UI. Since each developer is only modifying his own file, there shouldn't be any conflicts at the file level. Since the .mcr files are always only appended to, rsync should be able to update them quite efficiently (right?). And although there would be some duplication (each developer's repo would contain its own copy of most of the method versions), it would be O(developers) not O(versions) as MC1 is.

Thoughts?

We do a similar setup with MC1. I did it because there was no easy ssl support for http repositores.

http://www.squeaksource.com/monticellossl.html

Cheers Philippe

2008/8/14 Norbert Hartl norbert@hartl.name:

On Thu, 2008-08-14 at 13:21 +0200, Philippe Marschall wrote:

...

2008/8/14 Norbert Hartl norbert@hartl.name:

...

On Wed, 2008-08-13 at 16:26 -0700, Avi Bryant wrote:

...

On Wed, Aug 13, 2008 at 1:29 AM, Lukas Renggli renggli@gmail.com wrote:

...

I am would like to see some documentation on how to migrate from the old Monticello. Also I am eagerly awaiting the network repositories.

Here's a strategy that I think would work to allow networked collaboration with MC2 in its current state. Colin, let me know if I'm making any faulty assumptions here or misremembering how MC2 works.

1. For your project, create a separate file repository for each

developer. So, Lukas, if you, Colin and I were all collaborating on something, we would have lr.mcr, avi.mcr, and cwp.mcr. 2. Set up a script which rsyncs these three files to a shared location. Each developer should have this script set up to *upload* their own mcr and to *download* everyone else's. 3. Commit to your own repository (I would commit to avi.mcr), and then run the script. Or, have a cron job which runs it every few minutes.

Since the project has all three repos added, everyone's versions should show up together in the UI. Since each developer is only modifying his own file, there shouldn't be any conflicts at the file level. Since the .mcr files are always only appended to, rsync should be able to update them quite efficiently (right?). And although there would be some duplication (each developer's repo would contain its own copy of most of the method versions), it would be O(developers) not O(versions) as MC1 is.

Thoughts?

We do a similar setup with MC1. I did it because there was no easy ssl support for http repositores.

http://www.squeaksource.com/monticellossl.html

Thanks, I started in Oct 2006 the project in Jan 2007 :) Just kidding. I was aware of the curl plugin but not of this project. Thanks for pointing me to it! Is it usable on windows as well?

Yes, very much so: http://wiki.squeak.org/squeak/5865

Cheers Philippe

On Wed, Aug 13, 2008 at 7:56 PM, Andreas Raab andreas.raab@gmx.de wrote:

I'd appreciate a five minutes sales pitch pointing out what one can do with MC2. Either things one could not do or only barely do or maybe slowly do with MC1. Anything to help me understand why I would want to use MC2 instead of MC1 ;-)

The features I care the most about are these:

1. Faster merges. I have a couple of MC1 packages that are in the many thousands of versions. When I merge, it takes over a minute before the dialog even pops up showing me the changes. Making this less of a chore would be a great boon to my development workflow. 2. More efficient use of disk/network. My MC repository is several gigabytes, and I frequently transfer megabytes to commit a couple of hundred bytes of source changes. This isn't usually that big a problem, but when working on a laptop with a small harddrive or a slow connection, it's annoying. 3. Cherry picking. The worst part about merging with MC is that it's all or nothing: you have to integrate every change someone has made, or none of them. MC2 lets you pick a few changes now, a few changes later, and won't lose track of what you've done.

Others may have different priorities: for example, the fact that (IIRC) each instance variable (or class var, etc) is versioned separately, so that two people each adding an ivar to the same class won't conflict, might appeal, though it's not a problem I can remember ever running into. MC2 was also written with portability much more in mind, though MC1 is portable in practice (it works with full interop on both Squeak and Gemstone), whereas MC2 is only portable in theory so far. But the three listed above are the ones that will make a real impact on my daily work.

Avi

1. Faster merges. I have a couple of MC1 packages that are in the

many thousands of versions. When I merge, it takes over a minute before the dialog even pops up showing me the changes. Making this less of a chore would be a great boon to my development workflow. 2. More efficient use of disk/network. My MC repository is several gigabytes, and I frequently transfer megabytes to commit a couple of hundred bytes of source changes. This isn't usually that big a problem, but when working on a laptop with a small harddrive or a slow connection, it's annoying. 3. Cherry picking. The worst part about merging with MC is that it's all or nothing: you have to integrate every change someone has made, or none of them. MC2 lets you pick a few changes now, a few changes later, and won't lose track of what you've done.

4. Extensible. MC2 is extensible in many aspects, the GUI is based on OB and the versioning model is simple and can potentially used for other data than code. Take the example the task of versioning files together with Smalltalk code. A thing that is nearly impossible in MC1, though in one of the first versions of MC2 I could implement a working prototype within half an hour wihtout being exposed to documentation or the code before.

ever running into. MC2 was also written with portability much more in mind, though MC1 is portable in practice (it works with full interop on both Squeak and Gemstone), whereas MC2 is only portable in theory so far.

5. Portability. For me this is one of the most important points. MC2 clearly separates common, platform-dependent and GUI-specific code. The current implementation of MC hardcodes to many things to easily port to other Smalltalk dialects (GemStone did the impossible), and therefore people write their own libraries in VisualWorks, VST, GST and Dolphin to pull code from Squeak. This is a deadly one-way-road for open-source projects like Seaside or OB, because people working on these platforms are unable to contribute back conveniently. I hope that MC2 will be able to change that.

Lukas

On Thu, Aug 14, 2008 at 12:42 AM, Colin Putney cputney@wiresong.ca wrote:

On 13-Aug-08, at 11:27 PM, Lukas Renggli wrote:

1. Faster merges. I have a couple of MC1 packages that are in the

...

...

many thousands of versions. When I merge, it takes over a minute before the dialog even pops up showing me the changes. Making this less of a chore would be a great boon to my development workflow. 2. More efficient use of disk/network. My MC repository is several gigabytes, and I frequently transfer megabytes to commit a couple of hundred bytes of source changes. This isn't usually that big a problem, but when working on a laptop with a small harddrive or a slow connection, it's annoying. 3. Cherry picking. The worst part about merging with MC is that it's all or nothing: you have to integrate every change someone has made, or none of them. MC2 lets you pick a few changes now, a few changes later, and won't lose track of what you've done.

4. Extensible. MC2 is extensible in many aspects, the GUI is based on

OB and the versioning model is simple and can potentially used for other data than code. Take the example the task of versioning files together with Smalltalk code. A thing that is nearly impossible in MC1, though in one of the first versions of MC2 I could implement a working prototype within half an hour wihtout being exposed to documentation or the code before.

ever running into. MC2 was also written with portability much more in

...

mind, though MC1 is portable in practice (it works with full interop on both Squeak and Gemstone), whereas MC2 is only portable in theory so far.

5. Portability. For me this is one of the most important points. MC2

clearly separates common, platform-dependent and GUI-specific code. The current implementation of MC hardcodes to many things to easily port to other Smalltalk dialects (GemStone did the impossible), and therefore people write their own libraries in VisualWorks, VST, GST and Dolphin to pull code from Squeak. This is a deadly one-way-road for open-source projects like Seaside or OB, because people working on these platforms are unable to contribute back conveniently. I hope that MC2 will be able to change that.

6. Slices

In MC1 version history is tightly coupled to package structure. In MC2, version history is associated with the code, not its organization, which means that you can reorganize the code without losing the history. Further, you can have different organizational schema operating at the same time. For example, one developer can organize things into packages, while another uses change sets, and they can still use MC2 to do merges. MC2 its self is organized into a set of packages, but I use UnionSlices to bundle them up into a single snapshot for release.

Colin

This is the killer app for me :) It means I can version my closure bootstrap, which is too ticklish to maintain as packages. Is there a way to take existing changesets and make them slices? How do MC2 slices integrate with changesets? Do slices have names that match changesets or what? If I'm in a changeset do changes get added to the corresponding slice automatically? Where can I read up on this?

On 14-Aug-08, at 10:01 AM, Eliot Miranda wrote:

Is there a way to take existing changesets and make them slices? How do MC2 slices integrate with changesets? Do slices have names that match changesets or what? If I'm in a changeset do changes get added to the corresponding slice automatically? Where can I read up on this?

I guess this needs to be added to the documentation.

Yes, you can use existing change sets. When you create a ChangeSetSlice, MC prompts you with a menu of change sets. You choose one, and the new slice keeps a reference to it and acts as an adaptor between MC and the change set. You manage the change set normally, using the existing tools. When you take a snapshot of the slice it will include all the elements that are touched by the change set.

Colin

On 14-Aug-08, at 6:57 PM, Eliot Miranda wrote:

Does a ChangeSetSlice record the preamble and postscript? Do these get run automaticaly when a ChangeSetSlice is loaded?

No, that doesn't really fit with MC's versioning model.

Does your closure bootstrap have preamble and postscript? What do they do?

Colin

On 15-Aug-08, at 7:27 AM, Tony Garnock-Jones wrote:

So, MC likes to talk about nodes (whole artifacts) rather than edges (changes/deltas), primarily?

Yes. MC captures the state of an artifact and relates it to previous states. The deltas almost never reified - the only exception is when the user asks to view the differences between two states.

This is one of the things that darcs does very differently from most of the other DVCSs out there: most of them talk about nodes, darcs talks only about edges and infers the nodes when it needs to. It's an interesting tradeoff.

Darcs is interesting, certainly. The initial impetus for MC2 was a discussion Avi and I had about the Darcs theory of patches, but we ultimately decided to go in a different direction.

Colin

Eliot Miranda wrote:

On Fri, Aug 15, 2008 at 7:20 AM, Colin Putney <cputney@wiresong.ca mailto:cputney@wiresong.ca> wrote:

On 14-Aug-08, at 6:57 PM, Eliot Miranda wrote:

    Does a ChangeSetSlice record the preamble and postscript?  Do
    these get run automaticaly when a ChangeSetSlice is loaded?


No, that doesn't really fit with MC's versioning model.

Does your closure bootstrap have preamble and postscript? What do
they do?

There are a few. Preamble is essentially commentary so we can ignore it, but it would be great if MC2 supported a per-package or per-slice comment that allowed one to document the purpose, api and authorship et al of a package/slice.

The latest MC1.5/1.6 no longer manage the list of loaded packages themselves. PackageOrganizer is considered the master list, managing PackageInfo instances.

PackageInfo latest has a properties dictionary that is used for postscripts, preambles etc in MC1.

If I recall correctly MC1 serializes the instance of PackageInfo into the package zip file for reference purposes.

MC2 (which I havent looked at yet) could do likewise.

best regards

Keith

On Sun, Aug 17, 2008 at 4:44 AM, stephane ducasse stephane.ducasse@free.frwrote:

Hi colin

do you manage differently doit and class definitions in MC2 Slices (because changesets do not make a difference and this is a pain. I would really like to get rid of the old implementation of changesets

AFAICT changesets do differentiate between class definitions and doits. The probem is the changelist parser which does not, and that's reasonably easy to fix.

Stef

...

Is there a way to take existing changesets and make them slices? How do

...

MC2 slices integrate with changesets? Do slices have names that match changesets or what? If I'm in a changeset do changes get added to the corresponding slice automatically? Where can I read up on this?

I guess this needs to be added to the documentation.

Yes, you can use existing change sets. When you create a ChangeSetSlice, MC prompts you with a menu of change sets. You choose one, and the new slice keeps a reference to it and acts as an adaptor between MC and the change set. You manage the change set normally, using the existing tools. When you take a snapshot of the slice it will include all the elements that are touched by the change set.

Colin