Project Common Orbiter Installation

[tblaxland]

This marks "feature complete" state, so all initially planned features are in. Upload of addons and selection of remote branch have been added, so the cycle of push and pull is complete now.

Updated, it looks nice. I also noticed an unplanned feature - the "collapse remote" button (or whatever you call it) :speakcool:

By right-clicking branch-entries and clicking the remove context-entry, you can delete them again.

I've yet to play with this feature but I am curious as to whether or not removing the branch entry actually strips the branch or just removes its name.

These "branches" create partitions of the remote location's database. You can use them to e.g. separate users on big repositories or keep different addon-domains appart (historical, current, near-future, star-trek, etc.).

A very interesting idea, nice.

the non-publish strategie might come handy.

Like for example if you are building a "mega-addon" package? You could upload all the constituent addons from your local repo and not publish until the tip is in place?

Bug reports and suggestions are still welcome, though...

The main one on my list atm would be the sort-by and field order features of the list boxes that I mentioned earlier. In that same category I thought it might be nice to have a right-click context menu in the list box containing functions like:

Collapse all
Expand all
Expand all below here
​

Perhaps if you were to build such a context menu, the functions of the middle column of buttons could be moved to there?

Back to something you said earlier:

Just be aware, that stripping can take a long time...

On my system it seems that most of the time taken is due to the CPU chugging away compressing binaries that don't compress much anyway when it is building the patch queue. Is there anyway to get hg to build the patch queue uncompressed?

Anyway, I'll do some more testing over the next week or so. Keep up the good work.

 

[Face]

Updated, it looks nice. I also noticed an unplanned feature - the "collapse remote" button (or whatever you call it) :speakcool:

Ah yes, I forgot that...

I've yet to play with this feature but I am curious as to whether or not removing the branch entry actually strips the branch or just removes its name.

It just removes the name from the local list, nothing more. This branch-thing is somewhat rough, I've to think about the design a bit more. In the meantime it provides the basic functionality of checking in database-entries branch-wise, though.

Like for example if you are building a "mega-addon" package? You could upload all the constituent addons from your local repo and not publish until the tip is in place?

Well, the system detects the current database state of remote repos by means of the "local://localhost" tag. If a branch was specified, the tip of the branch is used.
In order to make the new database state appear as current to downloaders, the tag needs to be moved (much like git-branches), so you can do this via the "publish" function.

The initial idea here was to use hooks on the remote repo in order to give people certain access-rights. I.e. a repo admin can give normal users only push rights for uploading database states in certain branches (e.g. the user-branches), but not for publishing in the mainline. By uploading the database-state, but not publishing it, the admin can later on decide to merge the uploaded database-state into the mainline.

The main one on my list atm would be the sort-by and field order features of the list boxes that I mentioned earlier. In that same category I thought it might be nice to have a right-click context menu in the list box containing functions like:

Collapse all
Expand all
Expand all below here
​

Perhaps if you were to build such a context menu, the functions of the middle column of buttons could be moved to there?

Added to the TODO...

On my system it seems that most of the time taken is due to the CPU chugging away compressing binaries that don't compress much anyway when it is building the patch queue. Is there anyway to get hg to build the patch queue uncompressed?

Not at the moment. Strip doesn't have a compression flag. OTOH, strip uses the bundle system to store revisions while stripping out others, and bundle has the --type flag to define the compression mode.
It should be an easy fix to propagate this flag through to bundle...

That said, I don't want to fiddle around too much with the underlying VCS system, but maybe the patch gets accepted for the next hg release.

regards,
Face

 

[tblaxland]

Not at the moment. Strip doesn't have a compression flag. OTOH, strip uses the bundle system to store revisions while stripping out others, and bundle has the --type flag to define the compression mode.
It should be an easy fix to propagate this flag through to bundle...

I thought strip used qpop/qpush to acomplish its magic? Do they use bundle to do their work?

 

[Face]

I thought strip used qpop/qpush to acomplish its magic? Do they use bundle to do their work?

Thought so, too, but apparently it uses bundle: http://selenic.com/repo/hg-stable/file/5e44d9e562bc/mercurial/repair.py (line 68)

# Some revisions with rev > striprev may not be descendants of striprev.
# We have to find these revisions and put them in a bundle, so that
# we can restore them after the truncations.

EDIT: I've even found the exact place it specifies the compression mode with strip in the file pointed out above at line 14:

def _bundle(repo, bases, heads, node, suffix, extranodes=None):
    """create a bundle with the specified revisions as a backup"""
    cg = repo.changegroupsubset(bases, heads, 'strip', extranodes) 
    backupdir = repo.join("strip-backup") 
    if not os.path.isdir(backupdir): 
        os.mkdir(backupdir) 
    name = os.path.join(backupdir, "%s-%s" % (short(node), suffix)) 
    repo.ui.warn(_("saving bundle to %s\n") % name) 
    return changegroup.writebundle(cg, name, [B]"HG10BZ"[/B])

Putting "" instead of "HG10BZ" would do the trick...

EDIT: I've tried out the above mentioned fix, but had no luck with it. BUT I tried "HG10UN" instead of "", and that worked very well.

Here is how you could patch your TortoiseHG installation, too:

1. Download the attached zip archive. It contains a single compiled python file.
2. Locate the library.zip archive inside your TortoiseHG installation directory.
3. Extract and backup the /mercurial/repair.pyo file inside the archive (or backup the complete archive) and remove the file for the later.
4. Insert the downloaded compiled python file into the archive with the /mercurial/ path. (With WinZip, the best way would be to create a /mercurial/ folder in any drive's root directory and copy the pyc to it. Then use WinZip's add-function with the "save full path-info" option to add the file to the archive.)

Things speeded up quite a bit, even a strip of deep hidden revisions with about 300MB to backup worked under 10 secs for me. The same operation took about 2 mins before.

regards,
Face

 

[Face]

For the new 0.9 release of TortoiseHg, use the attached compiled file.

 

[tblaxland]

Things speeded up quite a bit, even a strip of deep hidden revisions with about 300MB to backup worked under 10 secs for me. The same operation took about 2 mins before.

I definitely get an improvement but I am feeling jealous of your PC ATM. 200MB took ~400 s with compression (100% CPU nearly the whole time) and ~100 s without compression.

 

[Face]

I definitely get an improvement but I am feeling jealous of your PC ATM. 200MB took ~400 s with compression (100% CPU nearly the whole time) and ~100 s without compression.

TBH, I'm working on a Dell Precision M6300 laptop. I think the key component limiting performance for you is HD speed.

 

[tblaxland]

For sure that is the case. The CPU use without compression was much lower, as expected. Dell Dimension 3000 with an old IDE HDD for me. I am keen to try it on my other machine which has a newer SATA drive.

 

[tblaxland]

I am keen to try it on my other machine which has a newer SATA drive.

The strip times were much better. So much so that I didn't bother timing them, but on the order of 20 s :thumbup:

BTW, I thought you might be intertested in this little experiment. I did a fresh install of the latest Orbiter Beta, and being lazy like usual, started looking convenient ways of installing my favourite addons. I couldn't see a way to do this directly using COI since it would pull the addons plus the 2006P1 parent into a disconnected branch. What I settled on was using the transplant command to drop the changesets on top of my Orbiter 2009 install. Worked like a charm! I can't believe the hoops I put myself through before I found DVCS...

 

[Face]

The strip times were much better. So much so that I didn't bother timing them, but on the order of 20 s :thumbup:

BTW, I thought you might be intertested in this little experiment. I did a fresh install of the latest Orbiter Beta, and being lazy like usual, started looking convenient ways of installing my favourite addons. I couldn't see a way to do this directly using COI since it would pull the addons plus the 2006P1 parent into a disconnected branch. What I settled on was using the transplant command to drop the changesets on top of my Orbiter 2009 install. Worked like a charm! I can't believe the hoops I put myself through before I found DVCS...

Yeah, I've done this for beta testing now and then. This would be what I want to implement as "dependency reorder" later on... just transplanting the addons to the other Orbiter base revision.

Also, I'm often transplanting the addon changesets on top of empty repositories for e.g. development or quick try-out. It is often faster doing this than fiddling with zips, especially if you have a complete "theme" of addons.

regards,
Face