On Jun 19, 2006, at 3:48 PM, Avi Bryant wrote:

On Jun 19, 2006, at 12:33 PM, Andreas Raab wrote:

...

Hi Guys -

I'm in the process of synchronizing two repositories which (effectively) comes down to copying the latest version of the package from repository A to repository B.

Problem is: When you do this, all the intermediate history gets lost. Unfortunately, that also includes all the log information about the changes that were accumulated and that is extremely annoying since if anyone asks me what has changed all I can do is to scrap the log info off each of the individual versions from the "right" repository.

I don't understand what intermediate history you're saying is getting lost. Each version of the package is self contained and carries the entire version history with it... is it just that you can't diff against intermediate versions because they aren't in the repository?

Yeah, that might be it.

Andreas, to synchronize the two repositories, you should copy to A everything that's only in B and vice versa. In other words, make both repositories contain the union of the two sets of versions. That should make it possible to find intermediate versions when doing diffs.

Colin

On Jun 19, 2006, at 4:10 PM, Andreas Raab wrote:

Colin Putney wrote:

...

Andreas, to synchronize the two repositories, you should copy to A everything that's only in B and vice versa. In other words, make both repositories contain the union of the two sets of versions. That should make it possible to find intermediate versions when doing diffs.

Doesn't that assume that this requires read-access on both repositories? That's not an option.

Uh, well, if you don't have read access, I don't think you can synch at all. If you meant "write access," then sure, you could just do a one-way synchronization. Copy to A any versions in B that are not already in A.

Colin

On Jun 19, 2006, at 4:59 PM, Andreas Raab wrote:

And yes, basically this is what I've been doing, e.g., do a merge of the versions in both repositories and publish the merged version to both.

Ah, but that's why you're not getting the intermediate versions. This is confusing, so I'm going to make up a scenario so I can speak more concretely and pedantically.

Let's imagine that I'm taking a plane ride and want to work on some Croquet stuff on the plane. Clearly I won't have access to the Croquet repository on the plane, so I want to synch my local repository with the master Croquet repository and be able to work offline.

In my local repository, I have the following versions:

FishTank-cwp.1 FishTank-cwp.3

I get the list of versions in the Croquet repository, and find it contains:

FishTank-cwp.2 FishTank-ar.3 FishTank-ar.4

Thus, I download FishTank-cwp.2, FishTank-ar.3 and FishTank-ar.4, and upload FishTank-cwp.3. Now the repositories are synchronized. They have the same contents, and no merging of versions was required:

FishTank-cwp.1 FishTank-cwp.2 FishTank-cwp.3 FishTank-ar.3 FishTank-ar.4

I get on the plane and I realize that FishTank is forked. We've both done some work based on cwp.2, and I want to merge it. So I merge cwp. 3 and ar.4, creating cwp.5. Since I've now got a local copy of cwp.2, the merge works out fine. Then I do some more work, creating cwp.6. Now I get to Japan, and it's time to synch my work back up to the master repository. So I upload cwp.5 and cwp.6, and now the repositories are synched again.

Does this make sense?

Colin

On Jun 19, 2006, at 4:08 PM, Andreas Raab wrote:

Well, maybe I'm not expressing myself very well ;-) Really, what I'm looking for is something like a "CHANGELOG" file, e.g., a summary of the log entries since version X. If that information (the log entry for each version in the history) is readily available I'd love to find out how to use it to generate such a change log between version X and Y. Basically just a summary like this:

Croquet-Copier-ar.6 (4 April 2006, 6:58:05 pm)

• replace underscore assignment with colon-equals

Croquet-Copier-ar.5 (7 March 2006, 8:02:41 pm)

• Homebase-Hedgehog integration

Croquet-Copier-ar.4 (31 January 2006, 10:48:12 pm)

• fix endian conversions for the copier

This was created by going to the hedgehog repository and http:// hedgehog.software.umn.edu:8888/hedgehogRC.html and extracting the information from the accessible versions. Unfortunately, if an intermediate version (Croquet-Copier-ar.5 for example) isn't accessible there is no way of finding out what exactly has changed in that version.

So if this information is indeed readily available please let me know where and how (and perhaps I can convince a SqueakSource developer to add the change log to the actions for a package version?).

Aha. This shouldn't be hard, and you won't need access to all the intermediate versions, since any version contains all the metadata about it's history. If you look at the VersionInfo for a particular version, you'll see that 'ancestors' contains an array of VersionInfo instances pertaining to the versions that it's based on. They form a tree, going back to the very first version of the package.

To create a CHANGELOG for the work done between versions X and Y, walk the ancestry trees to gather a set of VersionInfo instances that form the history of each version. Then find the difference of the sets, so that you have all the ancestors of Y that are not also ancestors of X. Sort by date and time, and collect the log messages.

No need for any versions other than X and Y.

Colin

Am 19.06.2006 um 22:08 schrieb Andreas Raab:

Avi Bryant wrote:

...

I don't understand what intermediate history you're saying is getting lost. Each version of the package is self contained and carries the entire version history with it... is it just that you can't diff against intermediate versions because they aren't in the repository?

Well, maybe I'm not expressing myself very well ;-) Really, what I'm looking for is something like a "CHANGELOG" file, e.g., a summary of the log entries since version X. If that information (the log entry for each version in the history) is readily available I'd love to find out how to use it to generate such a change log between version X and Y. Basically just a summary like this:

Croquet-Copier-ar.6 (4 April 2006, 6:58:05 pm)

• replace underscore assignment with colon-equals

Croquet-Copier-ar.5 (7 March 2006, 8:02:41 pm)

• Homebase-Hedgehog integration

Croquet-Copier-ar.4 (31 January 2006, 10:48:12 pm)

• fix endian conversions for the copier

This was created by going to the hedgehog repository and http:// hedgehog.software.umn.edu:8888/hedgehogRC.html and extracting the information from the accessible versions. Unfortunately, if an intermediate version (Croquet-Copier-ar.5 for example) isn't accessible there is no way of finding out what exactly has changed in that version.

So if this information is indeed readily available please let me know where and how (and perhaps I can convince a SqueakSource developer to add the change log to the actions for a package version?).

There's an incremental logging facility in MCConfigurations:

MCConfiguration whatChangedFrom: someOlderConfig to: someNewerConfig

It logs added, removed, and modified packages, and for a modified package the comments for all intermediate versions. For individual packages it uses

MCConfiguration changesIn: aPackage from: oldInfo to: newInfo on: aStream

- Bert -

Ah! Yes! Thank you! This is *just* what I was looking for. Mark - can we get we get this patch into the Croquet repository? I think it'll be in particular helpful for people trying to understand what happened, say between Croquet-Objects-das.113.mcz (the version in the Hedgehog release) and Croquet-Objects-ar.155.mcz (the version that I just sync-ed from the Qwaq repository ;-)

Cheers, - Andreas

Bert Freudenberg wrote:

Am 19.06.2006 um 22:08 schrieb Andreas Raab:

...

So if this information is indeed readily available please let me know where and how (and perhaps I can convince a SqueakSource developer to add the change log to the actions for a package version?).

Done:

http://source.impara.de/ss.html

• Bert -

On Jun 22, 2006, at 10:14 AM, Bert Freudenberg wrote:

Does anyone know a good order in which to display these versions? We currently use a a breadth-first order in the ancestor graph, which is also used when you click the "history" button in MC (a version usually has only one ancestor, but if a merge happend, it can have more than one, forming an acyclic directed graph).

Here's an example in chronological order:

1. A1 (--) - developer A starts a package
2. A2 (A1) - A produces more code
3. A3 (A2) - A fixes bugs
4. B4 (A3) - developer B branches
5. A4 (A3) - A continues on trunk
6. B5 (B4) - B develops on branch
7. B6 (B5) - B develops on branch
8. A5 (A4, B6) - A merges B's latest
9. A6 (A5) - A continues

but in breadth-first order this becomes:

9. A6 (A5) - A continues
10. A5 (A4, B6) - A merges B's latest
11. A4 (A3) - A continues on trunk
12. B6 (B5) - B develops on branch
13. A3 (A2) - A fixes bugs
14. B5 (B4) - B develops on branch
15. A2 (A1) - A produces more code
16. B4 (A3) - developer B branches
17. A1 (--) - developer A starts a package

... which is a bit counter-intuitive.

I wonder if there is some order or indentation scheme to better indicate the merge history. But it would have to be able to show even more complex cases than this rather simple example.

Hi Bert,

I think all merge histories can be thought of as Posets. Posets can be displayed as Hasse-Diagrams, especially using GraphViz with the nice adapter of John Pierce. (Technically speaken Hasse Diagrams come without arrowheads, but hey...)

You need an OS-Process enabled VM for using the graphviz package from John though, but below graph nodes and edges could then be displayed as morphs.

Cheers,

Markus

That's a GraphViz visualization too, same thing as Markus posted. I'd like to have a reasonably understandable text-only listing.

- Bert -

Am 22.06.2006 um 20:17 schrieb Philippe Marschall:

Hi

Lukas did something like that

http://www.cincomsmalltalk.com/userblogs/avi/blogView? showComments=true&entry=3291004466

Maybe we should nag the code out of him ;)

Cheers Philippe

2006/6/22, Markus Gaelli gaelli@emergent.de:

...

On Jun 22, 2006, at 10:14 AM, Bert Freudenberg wrote:

...

Does anyone know a good order in which to display these versions? We currently use a a breadth-first order in the ancestor graph, which is also used when you click the "history" button in MC (a version usually has only one ancestor, but if a merge happend, it can have more than one, forming an acyclic directed graph).

Here's an example in chronological order:

1. A1 (--) - developer A starts a package
2. A2 (A1) - A produces more code
3. A3 (A2) - A fixes bugs
4. B4 (A3) - developer B branches
5. A4 (A3) - A continues on trunk
6. B5 (B4) - B develops on branch
7. B6 (B5) - B develops on branch
8. A5 (A4, B6) - A merges B's latest
9. A6 (A5) - A continues

but in breadth-first order this becomes:

9. A6 (A5) - A continues
10. A5 (A4, B6) - A merges B's latest
11. A4 (A3) - A continues on trunk
12. B6 (B5) - B develops on branch
13. A3 (A2) - A fixes bugs
14. B5 (B4) - B develops on branch
15. A2 (A1) - A produces more code
16. B4 (A3) - developer B branches
17. A1 (--) - developer A starts a package

... which is a bit counter-intuitive.

I wonder if there is some order or indentation scheme to better indicate the merge history. But it would have to be able to show even more complex cases than this rather simple example.

Hi Bert,

I think all merge histories can be thought of as Posets. Posets can be displayed as Hasse-Diagrams, especially using GraphViz with the nice adapter of John Pierce. (Technically speaken Hasse Diagrams come without arrowheads, but hey...)

You need an OS-Process enabled VM for using the graphviz package from John though, but below graph nodes and edges could then be displayed as morphs.

Cheers,

Markus