The Trunk: Monticello-ar.379.mcz

Andreas Raab uploaded a new version of Monticello to project The Trunk:
http://source.squeak.org/trunk/Monticello-ar.379.mcz

==================== Summary ====================

Name: Monticello-ar.379
Author: ar
Time: 9 March 2010, 5:17:17.573 pm
UUID: aa6c11d2-d53c-e44d-b802-e10b6f2d2091
Ancestors: Monticello-ar.378

Put the newer version check back into saveVersion. It prevents accidental commits when there are newer (unmerged) versions in the repository. The test got lost probably accidentally a while ago; if the removal was deliberate we should make this a preference (I'm too lazy to live without it :-)


=============== Diff against Monticello-ar.378 ===============

Item was changed:
  ----- Method: MCWorkingCopyBrowser>>saveVersion (in category 'actions') -----
  saveVersion
  | repo |
  self canSave ifFalse: [^self].
+ self checkForNewerVersions ifFalse: [^self].
  repo := self repository.
  workingCopy newVersion ifNotNil:
  [:v |
  (MCVersionInspector new version: v) show.
  Cursor wait showWhile: [repo storeVersion: v].
  MCCacheRepository default cacheAllFileNamesDuring:
  [repo cacheAllFileNamesDuring:
  [v allAvailableDependenciesDo:
  [:dep |
  (repo includesVersionNamed: dep info name)
  ifFalse: [repo storeVersion: dep]]]]]!

Item was changed:
  SystemOrganization addCategory: #'Monticello-Base'!
  SystemOrganization addCategory: #'Monticello-Chunk Format'!
  SystemOrganization addCategory: #'Monticello-Loading'!
  SystemOrganization addCategory: #'Monticello-Merging'!
  SystemOrganization addCategory: #'Monticello-Modeling'!
  SystemOrganization addCategory: #'Monticello-Patching'!
  SystemOrganization addCategory: #'Monticello-Repositories'!
  SystemOrganization addCategory: #'Monticello-Storing'!
  SystemOrganization addCategory: #'Monticello-UI'!
  SystemOrganization addCategory: #'Monticello-Versioning'!
- SystemOrganization addCategory: #'Monticello-Mocks'!

On 2010-03-10, at 1:17 AM, [hidden email] wrote:

> Put the newer version check back into saveVersion. It prevents accidental commits when there are newer (unmerged) versions in the repository. The test got lost probably accidentally a while ago; if the removal was deliberate we should make this a preference (I'm too lazy to live without it :-)

I removed it because it's completely unnecessary. Monticello has no problem committing when there are newer versions out there. In fact, in that situation is better to commit anyway, and merge afterwards.

Colin

On 2010-03-09, at 7:33 PM, Eliot Miranda wrote:

> But I find knowing there's a newer version is /really/ useful.  It's all too easy to miss that someone else has updated your pet package with good stuff and plough on loosing their changes in the mists of time.  I vote for keeping the check-in.  It doesn't stop you form committing but has the huge advantage of knowing that a merge might be in your future.

Why not just open the repository browser after you've committed? Any unmerged versions would be displayed in bold.

Come to think of it, that would be more useful than opening the version inspector the way we do now.

Colin

On 10.03.2010, at 05:06, Colin Putney wrote:
This depends on the usage style I think. You can use Monticello in "distributed" style where there is no clear head, or "linear" style where the highest-numbered revision is significant. The Trunk's update mechanism uses the latter so I find the warning useful in that setting.

- Bert -

On 2010-03-10, at 2:24 AM, Bert Freudenberg wrote:

No. It's always better to commit first and merge afterward. If you have a collaboration style where the "head" is an important concept, you just merge right after committing, rather than at "integration time."

Colin

On 3/10/2010 5:11 PM, Colin Putney wrote:
It's interesting to see the different styles at work. For me, having the
notifier makes the overall workflow much more efficient. Take trunk for
example (our internal workflow is very similar): If you get a reminder
that there's something "ahead" of your commit, you hit update and it's
done in about ten seconds or so. Conflicts are rare so there mostly
isn't anything else to do.

Contrast this with the alternative: It implies that for *every* commit
you need to check the repository if there is a potential conflict (this
is why I said "I'm too lazy" in the checkin comment). If there is, you
need to select the unmerged version(s), merge them, write a change
comment, save them back. Repeat that for every commit. After a while
you're so tired out that you don't check and it goes okay, until you get
really bitten. That's the point when you start wondering why MC can't
tell you that there's stuff you need to merge. At least that's the way
it worked for me :-)

BTW, like I said earlier, I'll be happy to make that a preference.
Different people work differently, no need to slow you down with
something that serves no purpose in your chosen workflow.

Cheers,
   - Andreas

On 11 March 2010 03:51, Andreas Raab <[hidden email]> wrote:
Andreas, i think that checking the repo before commit is brittle thing:
a) You not always comitting into same repository.
b) A remote repository is not always accessible, and so, one may
simply save a file into local filesystem, and then manually copy it to
the server.
c) a most insulting thing is, that when you clicking 'save', it trying
to connect to the net _before_ saving a file on local repository, and
throwing an exception into your face instead of doing a simplest
possible thing - just save it.


> Cheers,
>  - Andreas


--
Best regards,
Igor Stasenko AKA sig.

On 3/10/2010 6:54 PM, Igor Stasenko wrote:
> Andreas, i think that checking the repo before commit is brittle thing:
> a) You not always comitting into same repository.
> b) A remote repository is not always accessible, and so, one may
> simply save a file into local filesystem, and then manually copy it to
> the server.
> c) a most insulting thing is, that when you clicking 'save', it trying
> to connect to the net _before_ saving a file on local repository, and
> throwing an exception into your face instead of doing a simplest
> possible thing - just save it.

We simply have different working styles. None of the above applies to my
workflows. For example, I *do* commit into the same repostories
practically always (if I don't then it's because I'm doing an explicit
merge and single false positive really doesn't matter) and my remote
repositories *are* always accessible (if they aren't I call up our admin
and give him an earful) and since MC is going to commit it to the
repository anyway, having it contact it sooner rather than later makes
absolutely no difference to me.

I'm not saying you have to use this style, I'm saying it works for me
and is much more efficient than the alternatives. In particular checking
a repository after each commit is something that I just can't be
bothered with. Doing this kind of mechanical stuff is exactly what tools
are for.

Cheers,
   - Andreas

On 2010-03-10, at 5:51 PM, Andreas Raab wrote:

>> No. It's always better to commit first and merge afterward. If you have a collaboration style where the "head" is an important concept, you just merge right after committing, rather than at "integration time."
>
> It's interesting to see the different styles at work. For me, having the notifier makes the overall workflow much more efficient. Take trunk for example (our internal workflow is very similar): If you get a reminder that there's something "ahead" of your commit, you hit update and it's done in about ten seconds or so. Conflicts are rare so there mostly isn't anything else to do.
>
> Contrast this with the alternative: It implies that for *every* commit you need to check the repository if there is a potential conflict (this is why I said "I'm too lazy" in the checkin comment). If there is, you need to select the unmerged version(s), merge them, write a change comment, save them back. Repeat that for every commit. After a while you're so tired out that you don't check and it goes okay, until you get really bitten. That's the point when you start wondering why MC can't tell you that there's stuff you need to merge. At least that's the way it worked for me :-)
>
> BTW, like I said earlier, I'll be happy to make that a preference. Different people work differently, no need to slow you down with something that serves no purpose in your chosen workflow.

Well, if you really must have such a check, then yes, please make it a preference.

But I think we're talking past each other. It really is better, from a package-history point of view, to commit regardless of what else is in the repository, and merge afterward. If the UI makes that too difficult, fine, let's fix *that* problem.

What about a preference that automatically merges after a commit? It would go something like this:

- you click save, type a log message, click accept.
- MC saves a new version of the package, as usual.
- If the preference is set, it checks the repository for unmerged versions. For each one it finds:
        - MC does an update, merging that version into your image
                - if there are conflicts, you get a dialog, otherwise it's silent
                - MC saves the merged version back to the repository, with an automatically generated commit message

Colin

On 2010-03-10, at 7:34 PM, Colin Putney wrote:

>> BTW, like I said earlier, I'll be happy to make that a preference. Different people work differently, no need to slow you down with something that serves no purpose in your chosen workflow.
>
> But I think we're talking past each other. It really is better, from a package-history point of view, to commit regardless of what else is in the repository, and merge afterward. If the UI makes that too difficult, fine, let's fix *that* problem.

On second thought, let's just go with the preference. I should know better than to try to convince an engineer to change the way he works. As long as it doesn't get in the way for the rest of us, it's fine.

Colin

On 3/10/2010 7:34 PM, Colin Putney wrote:
> Well, if you really must have such a check, then yes, please make it a preference.
>
> But I think we're talking past each other. It really is better, from a package-history point of view, to commit regardless of what else is in the repository, and merge afterward.

Wow. I'm amazed to hear you say that. Package history is specifically
one of the main reason why I prefer merging before commit. For example,
let's look at the package history of the System package in current trunk:

System-ar.290: Ancestors: System-ar.285, System-laza.289 ==+--+
System-ar.285: Ancestors: System-ar.284 <==================+  |
System-laza.289: Ancestors: System-nice.288----------------+--+
System-ar.284: Ancestors: System-dtl.283, System-ar.283<===+  | <-+
System-nice.288: Ancestors: System-nice.287 <--------------+--+   |
System-dtl.283 Ancestors: System-ar.282 <==================+  |   |
System-ar.283: Ancestors: System-ar.282 <==================+  | <-+
System-nice.287: Ancestors: System-nice.286 <--------------+--+   |
System-ar.282: Ancestors: System-ar.281 <==================+  |   |
System-nice.286: Ancestors: System-nice.285 <--------------+--+   |
System-ar.281: Ancestors: System-ar.280 <==================+  |   |
System-nice.285: Ancestors: System-nice.284, System-ar.284 <--+ --|
System-ar.280: Ancestors: System-ar.279 <==================+  |   |
System-nice.284: Ancestors: System-dtl.283 <------------------+---+
etc.

(I find this impossible to understand even *with* the ascii graph)

Let's assume I need to isolate a change, when it happened to either
verify if it was in a shipped product version or not. Look at the last
line in the above: If you're going down you might expect that
System-dtl.283 is below ("before") System-nice.284. But it's not. It's
actually *eight* lines on top of it. So is System-ar.284 merged by
System-nice.285. In other words there is no consistency in the graph -
you cannot assume that something that happened before something else
appears below it. Now let's look at a nice simple plain
merge-before-commit version history:

Traits-ar.282: Ancestors: Traits-ar.281   <-+
Traits-ar.281: Ancestors: Traits-nice.280 <-+
Traits-nice.280: Ancestors: Traits-ar.279 <-+
Traits-ar.279: Ancestors: Traits-ar.278   <-+
Traits-ar.278: Ancestors: Traits-nice.277 <-+
Traits-nice.277: Ancestors: Traits-ul.276 <-+
etc.

How's that for simplicity? I don't need the ascii graph to understand
the relation between the package versions, I can simply scroll through
the version history can find the package that I'm interested in, or use
binary subdivision to compare changes to see when a change was made.

Nothing personal, Colin, I really appreciate what you guys have been
doing but I don't see how one could possibly say that merge-after-commit
is better for package history. The precise opposite seems to be true.

Cheers,
   - Andreas

On 11 March 2010 05:29, Andreas Raab <[hidden email]> wrote:
You know, i had problems several times because i was assuming, that i
always can access to remote repository
and commit things right away.
And then i lost the packages, lost the commit history because of that.

> I'm not saying you have to use this style, I'm saying it works for me and is
> much more efficient than the alternatives. In particular checking a
> repository after each commit is something that I just can't be bothered
> with. Doing this kind of mechanical stuff is exactly what tools are for.
>

Its ok to check _after_ you successfully commit. But not before. See my point?

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 3/10/2010 8:44 PM, Igor Stasenko wrote:
Fair enough. When that happens we'll fire our admin (just kidding :-)

Seriously, I just don't care about this any longer. I expect my network
to be up, I expect my VPN to be up, I expect my repository to be up.
Period. For work, we switched to Gemstone for precisely the reasons of
stability and availability and I can only recommend that to anyone who
really needs the repository to be up and running. For Squeak, I'm fine
to save my image until squeaksource.com  or source.squeak.org is back up
(but the latter has been markedly improving after we updated it to run
on trunk).

>> I'm not saying you have to use this style, I'm saying it works for me and is
>> much more efficient than the alternatives. In particular checking a
>> repository after each commit is something that I just can't be bothered
>> with. Doing this kind of mechanical stuff is exactly what tools are for.
>>
>
> Its ok to check _after_ you successfully commit. But not before. See my point?

I see your point. I simply disagree with it. It's perfectly fine to
check before commit.

Cheers,
   - Andreas

On 2010-03-10, at 8:41 PM, Andreas Raab wrote:

>> But I think we're talking past each other. It really is better, from a package-history point of view, to commit regardless of what else is in the repository, and merge afterward.
>
> Wow. I'm amazed to hear you say that. Package history is specifically one of the main reason why I prefer merging before commit. For example, let's look at the package history of the System package in current trunk:
>>

[snip ascii graph]

> (I find this impossible to understand even *with* the ascii graph)
>
> Let's assume I need to isolate a change, when it happened to either verify if it was in a shipped product version or not. Look at the last line in the above: If you're going down you might expect that System-dtl.283 is below ("before") System-nice.284. But it's not. It's actually *eight* lines on top of it. So is System-ar.284 merged by System-nice.285. In other words there is no consistency in the graph - you cannot assume that something that happened before something else appears below it. Now let's look at a nice simple plain merge-before-commit version history:

Ok, I get it. You like to merge first because it generates *simpler* package history. I like to merge afterwards because it generates more *complete* package history.  

When you merge first, you lose the state of the package you were about to commit. When you save first, that information is available for trouble shooting later. If you have to go back and isolate a problem, you can tell whether it was introduced by changes a developer made while coding or during a merge. In either case it's easier to understand the set of changes, because they're a coherent unit - either a unit of development by a single developer, or a merge - rather than a mixture of several sets of changes.

But yeah, it's easier to track down a single change when the package history is linear.

> Nothing personal, Colin, I really appreciate what you guys have been doing but I don't see how one could possibly say that merge-after-commit is better for package history. The precise opposite seems to be true.

No worries. As I said in another post, I'm fine with making it a preference.

I think this is essentially a UI problem - bushy history graph is too hard to understand the way it's presented. The "best" fix would be to have better tools for examining package history and differences between package versions, but that's a big project. In the meantime, the preference will let us work around the problem in our respective ways.

Colin

On 3/10/2010 9:37 PM, Colin Putney wrote:
> Ok, I get it. You like to merge first because it generates *simpler* package history. I like to merge afterwards because it generates more *complete* package history.
>
> When you merge first, you lose the state of the package you were about to commit. When you save first, that information is available for trouble shooting later. If you have to go back and isolate a problem, you can tell whether it was introduced by changes a developer made while coding or during a merge. In either case it's easier to understand the set of changes, because they're a coherent unit - either a unit of development by a single developer, or a merge - rather than a mixture of several sets of changes.

I see what you're saying. I think it partly depends on what you usually
need to do with package history - for me, most of the time the question
is when a change was introduced, whether it was the result of a merge or
development is secondary.

Here's an idea for MC2: Use UTC time stamps and order the history
strictly by time. Given non-trivial package histories that is the one
that would be most useful to me. Alternatively, colorize branches.

> No worries. As I said in another post, I'm fine with making it a preference.
>
> I think this is essentially a UI problem - bushy history graph is too hard to understand the way it's presented. The "best" fix would be to have better tools for examining package history and differences between package versions, but that's a big project. In the meantime, the preference will let us work around the problem in our respective ways.

Pretty much all of it, yes. Basically it's an exercise in optimizing
various workflows.

Cheers,
   - Andreas

I am with Colin's choice.
Consider my workflow: i done doing something and decided to commit,
take a nap, go watch TV, or do anything
i need. So, when i press commit, i mean: i am done for today, save my
work, and let me do something else.
But going Anreases workflow i will be unable to commit before i megre
my stuff with somebody's else, which may take
from a few minutes up to multiple hours of work.

On 11 March 2010 07:55, Andreas Raab <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.