Nabble - Mercurial

Re: pulling changes to branch of my choice?

2009-11-28T04:41:23Z

On Sat, Nov 28, 2009 at 3:46 AM, Gilles Moris <gilles.moris@...> wrote:

> So now, I just declare the bundled rebase extension in my .hgrc and simply
> use the added --rebase option when I pull, to restack my currently pushed
> patches:
> % hg pull --rebase

Perfect! Thank you.

--
Dilip
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: knowing last chanegset pulled from remote

2009-11-28T03:50:23Z

Igor Lautar <igor.lautar@...> writes:

> On Wed, Nov 25, 2009 at 9:51 PM, Igor Lautar <igor.lautar@...> wrote:
>> On Wed, Nov 25, 2009 at 9:11 PM, Martin Geisler <mg@...> wrote:
>>> Perhaps you can add a local tag to mark the newest pulled changeset.
>>> There is a post-pull hook (there are pre-* and post-* hooks for all
>>> commands) which you could use to local tag 'tip' as 'latest-pulled'.
>>> You'll want something like
>>>
>>> [hooks]
>>> post-pull = hg tag --local --force --rev tip latest-pulled
>>
>> Sounds like it could fit in, I'll give it a go and report back.
>
> Update.
>
> Tagging proposed works for tip, but what if I pull multiple heads with
> single pull? I would like to tag all heads pulled.

I'm afraid you'll need to do a bit of scripting...

--
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

attachment0 (203 bytes) Download Attachment

Re: Patchbomb email format

2009-11-28T03:48:32Z

Chris Webb <chris@...> writes:

> I've been trying out the patchbomb extension for the first time, and
> I'm attempting to get it to format patches in the standard style
> that's popular on linux-kernel, including a diffstat:
>
> Subject: CHANGELOG[0]
> [other header lines]
>
> CHANGELOG[1:]
> ---
> DIFFSTAT
>
> PATCH
>
> I tried
>
> hg email --plain --diffstat --git --test --rev qbase --to '' --cc ''
>
> but this generates a format with the diffstat ahead of the changelog
> and a strange double newline after the diffstat:
>
> Subject: CHANGELOG[0]
> [other header lines]
>
> DIFFSTAT
>
>
> CHANGELOG[1:]
>
> PATCH
>
> Am I using the wrong options?

Nope, you cannot get the format you ask for without patching patchbomb.

> Reading the code, it doesn't look like any combination of flags will
> give a 'standard' email patch with diffstat after the changelog,
> separated by the "don't include this text in the changelog separator"
> (---).

I've never heard of the "---"-separator before and I don't think
Mercurial will recognize it when importing patches. I guess it's a
standard in the Git community?

> If I'm right that this is currently not achievable, I'm happy to send
> a patch to change the format to put the diffstat below the changelog,
> but is it worth making it optional? Diffstat at the top seems quite an
> odd behaviour, but maybe some people prefer it?

Without the --plain option, I think the current format makes more sense:

Subject: [PATCH] CHANGELOG[0]

DIFFSTAT

# HG changeset patch
# User Martin Geisler <mg@...>
# Date 1259273459 -3600
# Node ID 5e4ef56b4d420ca8f28964114a49c26508ab34c0
# Parent 15a1fe1fee5ce89e0069a4a856f39faeb8261b56
CHANGELOG[1:]

PATCH

The idea is that the chunk from "# HG changeset patch" until the end is
the patch -- the extra information (diffstat) is put outside of the
patch. So the result is very similar to simply composing a mail and then
inserting the output of 'hg export' at the bottom.

However, for your purpose, I can see why the it looks better to have the
diffstat "mixed" with the commit message. If we can recognize it
reliably by the "---" line and filter out the diffstat, then I would be
happy to support this format.

--
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

attachment0 (203 bytes) Download Attachment

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-28T02:43:42Z

On Fri, Nov 27, 2009 at 06:59:12PM -0800, Peter Hosey wrote:
> On Nov 27, 2009, at 08:50:12, Benoit Boissinot wrote:
> >Or maybe do merge with the same patch applied to the previous parent.
>
> I'm not sure what you're suggesting here. I'm talking about patches
> in mq, which have no explicit parent.

It doesn't that hg couldn't store the previous parent somewhere.

> And the usual case when I have to edit a patch is when I've just
> edited the immediately-preceding patch.

Indeed it doesn't work for this case.

regards,

Benoit

--
:wq
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-28T02:10:56Z

2009/11/28 Peter Hosey <boredzo@...>:
> On Nov 26, 2009, at 23:53:10, Peter Arrenbrecht wrote:
>>
>> So, are you using the fact that mq stores the patch files physically on
>> disk in your workflows? If so, how?
>
> I sometimes have to hand-edit the patches because mq is so finicky about
> patches having to *exactly match* whatever's in the source code. I would
> welcome a real solution to that problem.

+1 on this. When I need to update an outdated mq patch, I sometimes
find it easier to edit manually the patch to include the changes in
the context instead of merging manually. Common cases (top of my head,
might be incorrect): indentation changes, variable name changes, or
refactoring in main repo, combined to relatively big mq patches to
update.

But it does not happen often. I think I can fallback on exporting the
patch, tweaking it and reimport it. Maybe.

--
Nicolas Dumazet — NicDumZ
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: pulling changes to branch of my choice?

2009-11-28T00:51:32Z

On Sat, Nov 21, 2009 at 2:36 PM, Martin Geisler <mg@...> wrote:

> Dilip M <dilipm79@...> writes:
>
>> Sorry for this basic question..
>>
>> I have a repo "main". A colleagues of mine have cloned it. Now they have
>> done some fixes and asked to me pull it. Now I create a separate branch for
>> this pull activity. (example: hg branch pulled-changes). I change the "
>> pulled-changes" (hg up pulled-changes).
>>
>> If I do a pull from my colleagues repo, I get their changes in default
>> branch, rather than pulled-changes branch.
>>
>> How do I pull changes from remote repo's to an named branch of my choice?
>
> You cannot, as Gilles said.
>
> In general, one should *not* think of named branches as an isolated
> container for a group of changesets. It is not the case that you can make a
> named branch and then pull stuff "into" this branch.
>
> Instead, you should think of named branches as *labels* for changesets. In
> Mercurial we've now begun using a named branch called "stable" for
> changesets that are designated for the next stable point-release (important
> bug fixes and documentation updates).
>
> One must decide on the branch name for a give changeset at the time it is
> created. In other words, one must "be" on the right branch since the branch
> name is inherited from the parent changeset. So when we receive a patch on
> the mercurial-devel list, we update to the appropriate branch:
>
> hg update stable
>
> and import the patch there:
>
> hg import patch
>
>
> If you know Subversion, then think of named branches as the sub-directories
> under "branches/" in Subversion. If I make a new sub-directory called
>
> branches/martin/
>
> and work happily there, then I should not expect to be able to change the
> branch name (the directory) in the revisions I've made there.
>
> What you can do is to merge the content of "branches/martin/" into "trunk/"
> and delete "branches/martin/". That does not change the fact that
> "branches/martin/" exists in previous revisions.
>
> Named branches work the same: you can merge them into the "default" branch
> (or some other branch) and close them. But the old changesets on the branch
> will still be on that branch. The branch name will also live on, in the same
> sense that the "branches/martin/" folder is still known to Subversion even
> though it might be deleted in the HEAD revision.

Thanks to Gilles, martin.

I read mq and it is just amazing. But I _feel_ there should be some definite
guide on mq alone. I failed to find one, which explains from basic & advance
usage across various different workflow. [ PS: I am not complaining ]

I read the articles across internet. Few of them speak qsave, few of them
speaks qcommit. I got bit confused.

The article from Marshall is very good.
http://blogs.sun.com/ace/entry/mq_mercurial_queues

Just thought of sharing....

HTH to someone new to hg like me :)

Cheers...

--
Dilip
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T18:59:12Z

On Nov 27, 2009, at 08:50:12, Benoit Boissinot wrote:
> Or maybe do merge with the same patch applied to the previous parent.

I'm not sure what you're suggesting here. I'm talking about patches in
mq, which have no explicit parent. And the usual case when I have to
edit a patch is when I've just edited the immediately-preceding patch.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T17:33:46Z

On 27/11/09 17:53, Peter Arrenbrecht wrote:

> People reading the devel list may have noticed I am trying to rethink
> and unify mq and pbranch. They are both solutions to what mpm calls
> malleable history. This is also the aspect that I'm interested in:
> malleable parts of history within an hg repo. So part of the plan is
> to get rid of the physical patch files by default. This would free us
> from a bunch of limitations inherited from quilt's approach to patch
> management. However, the latter must also have its merits.
>
> So, are you using the fact that mq stores the patch files physically
> on disk in your workflows? If so, how? What are the crucial aspects
> for you?
>
> Note: Import/export to quilt-style patch queues would still be
> supported, but the physical files would no longer be the master copy.

Yes, I'd care. I do not want the patches or their content be absorbed
into the repository. I want to be able to restore the repository to its
pristine condition by doing 'hg qpop -a' without losing the data in the
patches. By pristine I mean exactly as it would have been if I cloned
the remote repo.

Peter
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: What's next for pbranch?

2009-11-27T17:28:21Z

On 28/11/09 00:21, Christian Boos wrote:

> Peter Williams wrote:
>> On 26/11/09 10:21, Peter Williams wrote:
>>> On 26/11/09 00:05, Christian Boos wrote:
>>>> ...
>>>> Note that with Mercurial 1.4, you can now safely use 'hg rebase' for
>>>> rebasing your MQ patch queue.
>>>
>>> Does this mean that the rebase bugs have been fixed? I didn't notice the
>>> patches go in. It's good news if it does because rebase is a better
>>> solution than the 'qsave dance' described in the book.
>>
>> I've just checked the list of bugs and there are still some unresolved
>> ones that make the use of rebase with MQ inadvisable. So I'll abstain
>> for the time being.
>
> I think all the problems rebase had together with MQ are fixed:
>
> issue1561 unnecessary merge conflicts in rebase (resolved)
> issue1830 Rebase or merge bug (resolved)
> issue1835 `pull --rebase` doesn't rebase (need-eg)
>
> 1561 was the main issue [1], and 1830 was a duplicate.
> I was not able to reproduce 1835, so I asked for more details, but I
> think this should work as well.

Not exactly a fix but not much you can do about it (I guess).

> Btw, my original example of doing `hg pull; hg rebase -b qtip -d tip`
> for rebasing the applied patch on top of upstream changes can actually
> be achieved by doing a simple `hg pull --rebase`.
>
> Of the other issues involving rebase, the only real problem left seems
> to be 1867 [2], and that one involves the rebasing of a merge changeset.
> This is not something which can happen in the context of rebasing MQ
> patches, as by design MQ doesn't manage merge changesets.
>
> So did I miss something else?

1622 pull --rebase fails when a child of an mq patch is pulled
1807 rebase calls too many hooks

Not sure 1622 really matters (to me anyway as I would NEVER be pulling
the child of an mq patch) but 1807 does as it prevents the use of hooks
to prevent (accidentally) pushing when patches are applied.

Peter
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: "log -v" not showing files, but "log --debug" does

2009-11-27T17:27:25Z

On Fri, 2009-11-27 at 19:49 -0500, Greg Ward wrote:

> I'm looking at a rather strange changeset: every way to query
> Mercurial shows that it modified one file, *except* "hg log -v". That
> is, "log -v" seems to think this changeset modified nothing, but I
> know better, and so does the rest of Mercurial. The most striking
> oddity is that "log --debug" reveals the truth.
>
> Here is the "log --debug" version, which is correct:
>
> """
> changeset: 104305:207e192fbd10a21bd293c01b788d0bb68df2975c
> branch: PACS-3-8-3
> parent: 104291:2aff2c98fd87c696d31fe4e14241cce37f6a7700
> parent: 104304:7eeec0142aee531b860ce506ecbf8d5fc4e93a0d
> manifest: 103036:a781ed3076d529b4524b54268e26df62ddcf1df1
> user: Greg Ward <gward@*****>
> date: Thu Nov 26 21:02:43 2009 -0500
> files: LoadBuild/utilities/generatePacsVersion
> extra: branch=PACS-3-8-3
> description:
> generatePacsVersion: handle production builds from Mercurial.
> """
>
> There are many ways to confirm this view of reality: "diff -c 104305",
> "diff -r 104291:104305", "log -p -r 104305", compare output of
> "manifest --debug", "status --rev 104291 --rev 104305". All agree
> that this changeset modified exactly one file.
>
> But "log -v" does not agree; here is what it says:
>
> """
> changeset: 104305:207e192fbd10
> branch: PACS-3-8-3
> parent: 104291:2aff2c98fd87
> parent: 104304:7eeec0142aee
> user: Greg Ward <gward@*******>
> date: Thu Nov 26 21:02:43 2009 -0500
> description:
> generatePacsVersion: handle production builds from Mercurial.
> """
>
> Note the absence of any "files" line. WTF?!? I'm getting the same
> result with 1.3.1ish and current stable. Disabling all extensions
> doesn't change things. Any clue what's going on here?

Probably something related to it being a merge. The changelog only
internally records files that change relative to both parents.

--
http://selenic.com : development and support for Mercurial and Linux

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

"log -v" not showing files, but "log --debug" does

2009-11-27T16:49:38Z

I'm looking at a rather strange changeset: every way to query
Mercurial shows that it modified one file, *except* "hg log -v". That
is, "log -v" seems to think this changeset modified nothing, but I
know better, and so does the rest of Mercurial. The most striking
oddity is that "log --debug" reveals the truth.

Here is the "log --debug" version, which is correct:

"""
changeset: 104305:207e192fbd10a21bd293c01b788d0bb68df2975c
branch: PACS-3-8-3
parent: 104291:2aff2c98fd87c696d31fe4e14241cce37f6a7700
parent: 104304:7eeec0142aee531b860ce506ecbf8d5fc4e93a0d
manifest: 103036:a781ed3076d529b4524b54268e26df62ddcf1df1
user: Greg Ward <gward@*****>
date: Thu Nov 26 21:02:43 2009 -0500
files: LoadBuild/utilities/generatePacsVersion
extra: branch=PACS-3-8-3
description:
generatePacsVersion: handle production builds from Mercurial.
"""

There are many ways to confirm this view of reality: "diff -c 104305",
"diff -r 104291:104305", "log -p -r 104305", compare output of
"manifest --debug", "status --rev 104291 --rev 104305". All agree
that this changeset modified exactly one file.

But "log -v" does not agree; here is what it says:

"""
changeset: 104305:207e192fbd10
branch: PACS-3-8-3
parent: 104291:2aff2c98fd87
parent: 104304:7eeec0142aee
user: Greg Ward <gward@*******>
date: Thu Nov 26 21:02:43 2009 -0500
description:
generatePacsVersion: handle production builds from Mercurial.
"""

Note the absence of any "files" line. WTF?!? I'm getting the same
result with 1.3.1ish and current stable. Disabling all extensions
doesn't change things. Any clue what's going on here?

Greg
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: Question about subrepo usages

2009-11-27T14:49:00Z

On Thu, 2009-11-26 at 17:38 +0100, Axelle Ziegler wrote:

> I'm aware that my question might seem dumb, but I just want to make
> sure I'm not missing something.
>
> What we are after is a way to "share" our library repository, meaning,
> ideally :
> 1) When we clone a project repo, the library repo get cloned alongside
> 2) If we modify our libs in one project, the change gets pushed to
> the lib main repo when we push
> 3) When we pull a project the lib gets pulled alongside (so that
> changes in the remote repository are propagated to the local version
> of th libs)
>
> While 1) and 2) seem to be provided by suprepos with no further work,
> 3) isn't as far as I can see. Is it the case, or am I misunderstanding
> something ?

There are a number of reasons why the subrepo implementation delays
pulling subrepos until update, rather than recursively pulling a pull
time. Here are a few:

- it may be undesirable to pull subrepos (ie publishing the main repo)
- there's no good place to store subrepos if there's no checkout
- there's no unambiguous way to decide what to pull (multiple branches)
- if the subrepo config is broken, it breaks pull instead of just update
- pull doesn't apply to non-distributed systems that we'll eventually
support[1]

I think the current approach is probably the best compromise in terms of
simplicity and functionality. The biggest downside is you might not be
able to update locally if your subrepo sources are offline, but that can
happen in any case.

[1] Augie Fackler says he's working on adding SVN support. Git and CVS
support should be pretty simple too: the hgsubrepo class to support
Mercurial subrepos is only 75 lines.

--
http://selenic.com : development and support for Mercurial and Linux

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: pulling changes to branch of my choice?

2009-11-27T14:16:01Z

On Saturday 28 November 2009 09:51:32 am Dilip M wrote:
> Thanks to Gilles, martin.
>

You're welcomed.

> I read mq and it is just amazing. But I _feel_ there should be some
> definite guide on mq alone. I failed to find one, which explains from basic
> & advance usage across various different workflow. [ PS: I am not
> complaining ]
>

One of the reference documentations is definitely the hgbook at:
http://hgbook.red-bean.com/

Chapter 12 and 13 are dedicated to MQ (resp. Basic and Advanced)

> I read the articles across internet. Few of them speak qsave, few of them
> speaks qcommit. I got bit confused.

The qsave command was useful at a time there was no tools to rebase your
patches on an upstream repo. It was requiring a tedious and error prone
process described.
I've tried to make an extension called qrebase to automate all that, but that
have been obsoleted by the rebase extension [1] which is able to that and
much more.

So now, I just declare the bundled rebase extension in my .hgrc and simply use
the added --rebase option when I pull, to restack my currently pushed
patches:
% hg pull --rebase

Regards.
Gilles.

PS: note that there are questions about remaining bugs in 1.4 when using "hg
pull --rebase" in another thread. I never had problems with those, and I did
not see anybody complaining lately either, but it's worth mentioning.
[1] http://mercurial.selenic.com/wiki/RebaseExtension
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Tortoise and Savannah

2009-11-27T13:28:31Z

Hello all,
I've just registered a project on (Non)GNU Savannah site and I'm trying to
use TortoiseHg (and also the command line) to upload all my local repository
on the Savannah server. https://savannah.gnu.org/support/index.php?107140

I'm registered on Savannah and I have configured the repository according to
Savannah guidelines (http://savannah.gnu.org/maintenance/UsingHg) but I cannot
connect to the repository (it uses SSH).

The configuration file seems correct, to me. I'm using TortoiseHg 0.9.

So, I'm trying to push the modifications on Savannah, and I receive this
message: "Disconnected: No supported authentication methods available".
I've received, the first time I tried, the SSH connection message (key and so
on) but since I was busy doing too many things, I've not read it and I've also
probably mistyped the login name, that time, so I would like to try by
removing the already registered SSH and trying again.
Any idea on how to do this on this damn OS? (No, can't install gNewSense right
now, unfortunately...)

Also, is the hg file correct?

------------------------------------------
[paths]
default = ssh://MarcoBresciani@.../scacchi3d

[ui]
username = Marco Bresciani

[tortoisehg]
authorcolor = True

[web]
name = Scacchi 3D
description = Progetto e Sviluppo di un Sistema per il Gioco degli Scacchi
Tridimensionali
contact = Marco Bresciani <m.bresciani@...>

[email]
from = Marco Bresciani <m.bresciani@...>
------------------------------------------

Here they are my steps:
1. opened command prompt as administrator user;
2. "cd"ed inside the repository directory (same level as ".hg" directory;
3. checked repository config file to be sure about content (see previous
attachment);
4. ran "hg serve -A access.log -E error.log" at 21.33;
...

...
5. no news/changes or output (neither in the logs) at 21.50 but command
apparently still running (no exit firewall on hg, obviously);

------------------------------------------
------------------------------------------
------------------------------------------

Second attempt:
1. opened command prompt as administrator user;
2. "cd"ed inside the repository directory (same level as ".hg" directory;
3. checked repository config file to be sure about content (see previous
attachment);
4. ran "hg push -v --debug" at 21.40;
5. output is:

sto eseguendo ""C:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2
MarcoBresciani@... "hg -R scacchi3d serve --stdio""
sending hello command
sending between command
abortito: nessuna risposta accettabile dall'hg remoto!

where "sto eseguendo" means "I'm running" and "abortito: nessuna risposta
accettabile dall'hg remoto!", according to the translation file the actual
English message is: "no suitable response from remote hg".

------------------------------------------
------------------------------------------
------------------------------------------

Instead, using TortoiseHg "push" command I see an error popup dialog saying
"Disconnected: No supported authentication methods available". Same for
"incoming", "push" and "outgoing" modifications commands.

------------------------------------------
------------------------------------------
------------------------------------------

Any idea? :-(

Thanks,

Marco
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T12:47:06Z

On Thu, Nov 26, 2009 at 11:53 PM, Peter Arrenbrecht
<peter.arrenbrecht@...> wrote:

http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html#sec:mq:repo

To a limited degree I have turned the patches folder into a repository
itself to share patches amongst various copies of the main repository.
Seemed useful to me.

-kyle

>
> Note: Import/export to quilt-style patch queues would still be
> supported, but the physical files would no longer be the master copy.
>
> Cheers,
> -parren
> _______________________________________________
> Mercurial mailing list
> Mercurial@...
> http://selenic.com/mailman/listinfo/mercurial
>

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T09:10:36Z

Benoit Boissinot wrote:

> On Fri, Nov 27, 2009 at 05:35:51PM +0100, Christian Boos wrote:
>
>> Peter Hosey wrote:
>>
>>> On Nov 26, 2009, at 23:53:10, Peter Arrenbrecht wrote:
>>>
>>>> So, are you using the fact that mq stores the patch files
>>>> physically on disk in your workflows? If so, how?
>>>>
>>> I sometimes have to hand-edit the patches because mq is so finicky
>>> about patches having to *exactly match* whatever's in the source
>>> code. I would welcome a real solution to that problem.
>>>
>> Try apply the .rej file via wiggle [1].
>>
>> Now if hg would by itself fallback to word level merges when a chunk
>> fails to apply, that would be excellent ;-)
>>
>
> Or maybe do merge with the same patch applied to the previous parent.
>

But this would work only if you actually know what was that previous
parent. Maybe you got that patch from the bugtracker or elsewhere, and
if it was not produced by an `hg export` it will not have the parent hash.

Even in the case the patch was already in MQ before, when you do a qpop
the parent information will be lost. Would it be possible to write the
standard headers in the patch after a successful qpush? Maybe simply by
overwriting the patch with an hg export?

-- Christian

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T08:50:12Z

On Fri, Nov 27, 2009 at 05:35:51PM +0100, Christian Boos wrote:

> Peter Hosey wrote:
> >On Nov 26, 2009, at 23:53:10, Peter Arrenbrecht wrote:
> >>So, are you using the fact that mq stores the patch files
> >>physically on disk in your workflows? If so, how?
> >
> >I sometimes have to hand-edit the patches because mq is so finicky
> >about patches having to *exactly match* whatever's in the source
> >code. I would welcome a real solution to that problem.
>
> Try apply the .rej file via wiggle [1].
>
> Now if hg would by itself fallback to word level merges when a chunk
> fails to apply, that would be excellent ;-)

Or maybe do merge with the same patch applied to the previous parent.

Benoit

--
:wq
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T08:35:51Z

Peter Hosey wrote:
> On Nov 26, 2009, at 23:53:10, Peter Arrenbrecht wrote:
>> So, are you using the fact that mq stores the patch files physically
>> on disk in your workflows? If so, how?
>
> I sometimes have to hand-edit the patches because mq is so finicky
> about patches having to *exactly match* whatever's in the source code.
> I would welcome a real solution to that problem.

Try apply the .rej file via wiggle [1].

Now if hg would by itself fallback to word level merges when a chunk
fails to apply, that would be excellent ;-)

-- Christian

[1] - http://neil.brown.name/git?p=wiggle;a=summary

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T08:27:03Z

On Nov 26, 2009, at 23:53:10, Peter Arrenbrecht wrote:
> So, are you using the fact that mq stores the patch files physically
> on disk in your workflows? If so, how?

I sometimes have to hand-edit the patches because mq is so finicky
about patches having to *exactly match* whatever's in the source code.
I would welcome a real solution to that problem.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T06:33:08Z

Hello,

Peter Arrenbrecht wrote:

Sometimes I develop patches in a repository, and when I'm done apply them
directly into another with hg import. But a facility for exporting those patches
(either a special command or plain hg export) would probably be enough for me.

Thanks,
Wagner

> Note: Import/export to quilt-style patch queues would still be
> supported, but the physical files would no longer be the master copy.
>
> Cheers,
> -parren

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: What's next for pbranch?

2009-11-27T06:21:15Z

Peter Williams wrote:

> On 26/11/09 10:21, Peter Williams wrote:
>> On 26/11/09 00:05, Christian Boos wrote:
>>> ...
>>> Note that with Mercurial 1.4, you can now safely use 'hg rebase' for
>>> rebasing your MQ patch queue.
>>
>> Does this mean that the rebase bugs have been fixed? I didn't notice the
>> patches go in. It's good news if it does because rebase is a better
>> solution than the 'qsave dance' described in the book.
>
> I've just checked the list of bugs and there are still some unresolved
> ones that make the use of rebase with MQ inadvisable. So I'll abstain
> for the time being.

I think all the problems rebase had together with MQ are fixed:

issue1561 unnecessary merge conflicts in rebase (resolved)
issue1830 Rebase or merge bug (resolved)
issue1835 `pull --rebase` doesn't rebase (need-eg)

1561 was the main issue [1], and 1830 was a duplicate.
I was not able to reproduce 1835, so I asked for more details, but I
think this should work as well.
Btw, my original example of doing `hg pull; hg rebase -b qtip -d tip`
for rebasing the applied patch on top of upstream changes can actually
be achieved by doing a simple `hg pull --rebase`.

Of the other issues involving rebase, the only real problem left seems
to be 1867 [2], and that one involves the rebasing of a merge changeset.
This is not something which can happen in the context of rebasing MQ
patches, as by design MQ doesn't manage merge changesets.

So did I miss something else?

-- Christian

[1] - http://selenic.com/repo/hg/rev/49efeed49c94
[2] - http://mercurial.selenic.com/bts/issue1867

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T05:35:03Z

Hi,

2009/11/27 Peer Sommerlund <peer.sommerlund@...>:

> 2009/11/27 Peter Arrenbrecht <peter.arrenbrecht@...>
>>
>> So, are you using the fact that mq stores the patch files physically
>> on disk in your workflows? If so, how? What are the crucial aspects
>> for you?
>>
> In cases where I have several clones of a repository, I sometimes move patch
> files between repositories.
> I have several mini-projects for TortoiseHg, each of them have one or more
> repositories. The patch file moving occurs if if I fix a bug or make a new
> feature, while working on something else.

I guess that's the most important use case (I used it just before
posting ;-)), the other notable use case is to attach to a bug tracker
(that is, without 'hg export > tempfile' and later forgetting to
delete the file, or why it was there in the first place).

I think removing the patch files would lead to the same situation for
the first case.
Not that I'm against removing them, there might be a good way to do
this without the patches (e.g. transplant extension)

Peace,
Abderrahim
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: newline in branch name - how to recover repo

2009-11-27T04:09:59Z

On Fri, Nov 27, 2009 at 12:22 PM, Igor Lautar <igor.lautar@...> wrote:

> Hi All,
>
> I have a weird problem.
>
> Some history how we come to this state:
> - we migrated from svn
> - I've used hg convert to convert this svn repo to hg (using just
> part of whole repo)
> - convert was done on a subdirectory (ie. not trunk but 'src' dir inside it)
> - this was done for two branches
> - branchmap was used to link 'src' from trunk to 'default' and the
> one from branch to 'v1' (arbitrary names)
> - shamap was also used to properly link v1 with default
>
> How the weird problem. This was originally done on windows system and
> later moved to linux where repo was incrementally converted few times
> to sync. This is now final, as we moved to hg.
>
> However, it seams branchmap files (when moved from win to linux)
> somehow (CR/LF detection) managed to put extra newline into tag. This
> was not obvious from command-line tools (it does not display extra
> newline), but from hgtk log, I can see something like:
>
> 'default
> '
> and
> 'v1
> '
>
> It was weird to have 'default' tag show up in logs, but I (wrongly)
> ignored it. Stuff was also commited (and merged etc.) later on,
> introducing proper branch names.
>
> Now we have 4 branches:
> 'default'
> 'default
> '
> 'v1'
> 'v1
> '
>
> Interestingly enough, command line tools do not show newline,
> branchheads.cache looks like:
> <hash> tip
> <hash> default
> <hash> default
> <hash> v1
> <hash> v1
>
> and hg update [default|v1] does the wrong thing.
>
> How to fix this? I have no problem of doing complete hg convert on it
> as number of devs is small (two of us for now). Would hg convert be
> our best option?
>
> But this got me thinking. Its obviously a corner case in convert
> extension to create this, but should hg care for newline?
>
> Thx for ideas,
> Igor
>

(keeping old msg for mercurial-devel)

Should anyone be interested, hg convert preserves newline.

But the following patch did the trick:
diff -r d266aa7606ce hgext/convert/convcmd.py
--- a/hgext/convert/convcmd.py Wed Nov 18 00:19:42 2009 +0100
+++ b/hgext/convert/convcmd.py Fri Nov 27 12:54:10 2009 +0100
@@ -266,12 +266,13 @@
def cachecommit(self, rev):
commit = self.source.getcommit(rev)
commit.author = self.authors.get(commit.author, commit.author)
- commit.branch = self.branchmap.get(commit.branch, commit.branch)
+ commit.branch = self.branchmap.get(commit.branch,
commit.branch).strip()
self.commitcache[rev] = commit
return commit

def copy(self, rev):
commit = self.commitcache[rev]
+ commit.branch = commit.branch.strip()

changes = self.source.getchanges(rev)
if isinstance(changes, basestring):
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T03:25:58Z

On Fri, Nov 27, 2009 at 12:23 PM, Alpar Juttner
<ajuttner.list@...> wrote:
> On Fri, 2009-11-27 at 09:47 +0100, Igor Lautar wrote:
> Have you considered using
>
> hg qref -u
>
> for doinf this?

Well, I wasn't aware of it so I did what I found was fastest solution
at the time. Looking @ help of qref, it should work as well.

Thx for the tip,
Igor
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T03:23:46Z

On Fri, 2009-11-27 at 09:47 +0100, Igor Lautar wrote:

> On Fri, Nov 27, 2009 at 8:53 AM, Peter Arrenbrecht
> <peter.arrenbrecht@...> wrote:
> > So, are you using the fact that mq stores the patch files physically
> > on disk in your workflows? If so, how? What are the crucial aspects
> > for you?
>
> I've found it convenient on one occasion to change author of
> changesets using MQ patches. This was done using sed directly on
> patches on disk.
> Need for this was because user forgot to set his ui.username properly
> and commited w/o it.

Have you considered using

hg qref -u

for doinf this?

Regards,
Alpar

>
> Regards,
> _______________________________________________
> Mercurial mailing list
> Mercurial@...
> http://selenic.com/mailman/listinfo/mercurial

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

newline in branch name - how to recover repo

2009-11-27T03:22:05Z

Hi All,

I have a weird problem.

Some history how we come to this state:
- we migrated from svn
- I've used hg convert to convert this svn repo to hg (using just
part of whole repo)
- convert was done on a subdirectory (ie. not trunk but 'src' dir inside it)
- this was done for two branches
- branchmap was used to link 'src' from trunk to 'default' and the
one from branch to 'v1' (arbitrary names)
- shamap was also used to properly link v1 with default

How the weird problem. This was originally done on windows system and
later moved to linux where repo was incrementally converted few times
to sync. This is now final, as we moved to hg.

However, it seams branchmap files (when moved from win to linux)
somehow (CR/LF detection) managed to put extra newline into tag. This
was not obvious from command-line tools (it does not display extra
newline), but from hgtk log, I can see something like:

'default
'
and
'v1
'

It was weird to have 'default' tag show up in logs, but I (wrongly)
ignored it. Stuff was also commited (and merged etc.) later on,
introducing proper branch names.

Now we have 4 branches:
'default'
'default
'
'v1'
'v1
'

Interestingly enough, command line tools do not show newline,
branchheads.cache looks like:
<hash> tip
<hash> default
<hash> default
<hash> v1
<hash> v1

and hg update [default|v1] does the wrong thing.

How to fix this? I have no problem of doing complete hg convert on it
as number of devs is small (two of us for now). Would hg convert be
our best option?

But this got me thinking. Its obviously a corner case in convert
extension to create this, but should hg care for newline?

Thx for ideas,
Igor
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T02:50:34Z

On 27.11.2009 08:53, Peter Arrenbrecht wrote:

I think trying to start tweaking mq from this angle (unifying mq
and pbranch) is the wrong approach.

Accept the fact that mq and pbranch are two different things
and leave mq as it is.

Average users are still not using mq enough yet or have really
understood how it can be used. Trying to further tweak it *now* or
adding yet another variant in addition to mq and pbranch is just
the wrong approach.

Use what we have.

And no, mq is not broken or needs to be fixed.

Time would be better spent to improve access to the current
features of mq (and probably pbranch), instead of inventing yet
more complex or just "new" ones.

As such the new support for mq in the recently released
TortoiseHg 0.9 is a big step in the right direction.
And users would most likely benefit the most if mq support
in TortoiseHg could be improved and extended.
For example, being able to add patches to the queue from
within the GUI would be very nice to have. It doesn't even
have to be drag and drop.

To answer the question: yes I do use the fact that patches
are stored on disk by mq. I sometimes copy patches from one
repo to another, dropping them into the .hg/patches dir.

Although I must admit I haven't yet fully understood how
pbranch works and why it could be useful. I am currently
in the state of using mq regularly. Although it took me
quite some time to get comfortable using it. And this was *not*
mq's fault (at least not the fault of its basic design,
the ui is another story...).

Frankly, pbranch hasn't yet exited the "obscure" status for me
personally (which is most likely not the fault of pbranch,
since I went though a similar phase regarding mq).

The advent of support in TortoiseHg for mq has had a
big influence in this regard for me.

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T00:51:49Z

2009/11/27 Peter Arrenbrecht <peter.arrenbrecht@...>

So, are you using the fact that mq stores the patch files physically
on disk in your workflows? If so, how? What are the crucial aspects
for you?

In cases where I have several clones of a repository, I sometimes move patch files between repositories.

I have several mini-projects for TortoiseHg, each of them have one or more repositories. The patch file moving occurs if if I fix a bug or make a new feature, while working on something else.

Regards,

Peer

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-27T00:47:19Z

On Fri, Nov 27, 2009 at 8:53 AM, Peter Arrenbrecht
<peter.arrenbrecht@...> wrote:
> So, are you using the fact that mq stores the patch files physically
> on disk in your workflows? If so, how? What are the crucial aspects
> for you?

I've found it convenient on one occasion to change author of
changesets using MQ patches. This was done using sed directly on
patches on disk.
Need for this was because user forgot to set his ui.username properly
and commited w/o it.

Regards,
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

RE: Would you care if mq stopped storing patch files physically on disk?

2009-11-26T23:57:41Z

Sometimes I qpop. edit the patch directly and qpush again. I'm not sure if it's efficient method, but that means the answer to your question is "Yes".

--jyh

mercurial-bounces@... wrote:

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

RFC: Would you care if mq stopped storing patch files physically on disk?

2009-11-26T23:53:10Z

People reading the devel list may have noticed I am trying to rethink
and unify mq and pbranch. They are both solutions to what mpm calls
malleable history. This is also the aspect that I'm interested in:
malleable parts of history within an hg repo. So part of the plan is
to get rid of the physical patch files by default. This would free us
from a bunch of limitations inherited from quilt's approach to patch
management. However, the latter must also have its merits.

So, are you using the fact that mq stores the patch files physically
on disk in your workflows? If so, how? What are the crucial aspects
for you?

Note: Import/export to quilt-style patch queues would still be
supported, but the physical files would no longer be the master copy.

Cheers,
-parren
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: hg up and uncommitted deletes

2009-11-26T21:23:32Z

ok, i'll try to upgrade to a newer version. thanks for your help.
happy thanksgiving!

On Nov 26, 4:49 am, Matt Mackall <m...@...> wrote:

> On Tue, 2009-11-24 at 18:33 -0800, steve wrote:
> > i am doing the following with hg 1.0.2:
>
> > s@linux-2fjb:~/tmp> hg init repo
> > s@linux-2fjb:~/tmp> cd repo/
> > s@linux-2fjb:~/tmp/repo> touch foo.txt
> > s@linux-2fjb:~/tmp/repo> hg add foo.txt
> > s@linux-2fjb:~/tmp/repo> hg ci -m 'added foo' foo.txt
> > s@linux-2fjb:~/tmp/repo> hg mv foo.txt bar.txt
> > s@linux-2fjb:~/tmp/repo> hg stat .
> > A bar.txt
> > R foo.txt
> > s@linux-2fjb:~/tmp/repo> hg up
> > 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> > s@linux-2fjb:~/tmp/repo> hg stat .
> > A bar.txt
> > s@linux-2fjb:~/tmp/repo>
>
> > maybe i am just not understanding the differences between 'hg up' and
> > 'svn up'. afaik, 'hg pull' will pull updates from other repo into my
> > local repo, and that 'hg up' will update the local copy from the local
> > repo. since i didn't change my local repo, 'hg up' shouldn't do
> > anything. but instead, it undoes my uncommitted delete. i have a
> > habit of doing an update before committing. i want to figure out what
> > the expected behavior is so i could adapt accordingly.
>
> Updating to the parent of the working directory (rather than an actually
> newer revision) did act a little strangely pre-1.3. Recommend you update
> to a modern hg, which has a cleaner internal notion of a "backwards
> update" (where basically nothing happens in this case).
>
> --http://selenic.com: development and support for Mercurial and Linux
>
> _______________________________________________
> Mercurial mailing list
> Mercur...@...://selenic.com/mailman/listinfo/mercurial

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: TortoiseHg: Browsing Remote Repositories

2009-11-26T18:43:06Z

On Thu, Nov 26, 2009 at 5:57 PM, Stephen Rasku <mercurial@...> wrote:

> On Thu, Nov 26, 2009 at 15:46, Adrian Buehlmann <adrian@...> wrote:
>> On 27.11.2009 00:02, Stephen Rasku wrote:
>>> A quick question: Is it possible to use TortoiseHg to browse remote
>>> repositories without cloning them locally? If not, is that feature
>>> planned for the future?
>>>
>>
>> No, this is not possible.
>>
>> No, it is not planned.
>>
>> And it is very unlikely to be planned ever because Mercurial is a DVCS
>> (= use your local history).
>
> But I don't necessarily want to have a local copy of a large
> repository on my local system. I can currently view history remotely
> running "hg serve" or hgwebdir on the remote machine. I would think
> that Tortoise could use a similar mechanism to provide remote viewing
> but providing a richer interface than the web interface does.

The work required dwarfs any benefit you would get from such a
feature. I don't see TortoiseHg even trying to do anything like this
before Mercurial supported some sort of remote API, and the chances of
that happening are pretty slim.

It's certainly not on either project's road map.

--
Steve Borho
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: What's next for pbranch?

2009-11-26T16:46:23Z

On 26/11/09 10:21, Peter Williams wrote:

> On 26/11/09 00:05, Christian Boos wrote:
>> Peter Arrenbrecht wrote:
>>> On Wed, Nov 25, 2009 at 6:56 AM, Peter Williams
>>> <pwil3058@...> wrote:
>>> [snip]
>>>> That doesn't mean that MQ doesn't have its uses. For its intended
>>>> purpose,
>>>> keeping a set of local patches against an externally managed source
>>>> tree
>>>> (e.g. the Linux kernel), it is superior to pbranch.
>>>>
>>>> And I'm sure that for some purposes pbranch is superior to MQ.
>>>
>>> Actually, for the specific case you mention I personally find pbranch
>>> to be superior. I use it to maintain a set of local patches against hg
>>> crew, for instance. Unlike mq pbranch uses regular hg merges for
>>> updating the patches against changes in upstream.
>>
>> Note that with Mercurial 1.4, you can now safely use 'hg rebase' for
>> rebasing your MQ patch queue.
>
> Does this mean that the rebase bugs have been fixed? I didn't notice the
> patches go in. It's good news if it does because rebase is a better
> solution than the 'qsave dance' described in the book.

I've just checked the list of bugs and there are still some unresolved
ones that make the use of rebase with MQ inadvisable. So I'll abstain
for the time being.

Peter
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

Re: What's next for pbranch?

2009-11-26T16:31:14Z

On 26/11/09 18:12, Peter Arrenbrecht wrote:

> On Thu, Nov 26, 2009 at 1:16 AM, Peter Williams<pwil3058@...> wrote:
>> On 25/11/09 22:48, Peter Arrenbrecht wrote:
>>>
>>> On Wed, Nov 25, 2009 at 6:56 AM, Peter Williams<pwil3058@...>
>>> wrote:
>>> [snip]
>>>>
>>>> That doesn't mean that MQ doesn't have its uses. For its intended
>>>> purpose,
>>>> keeping a set of local patches against an externally managed source tree
>>>> (e.g. the Linux kernel), it is superior to pbranch.
>>>>
>>>> And I'm sure that for some purposes pbranch is superior to MQ.
>>>
>>> Actually, for the specific case you mention I personally find pbranch
>>> to be superior. I use it to maintain a set of local patches against hg
>>> crew, for instance. Unlike mq pbranch uses regular hg merges for
>>> updating the patches against changes in upstream.
>>
>> It may be that I haven't got my head around how pbranch operates (in spite
>> of adding GUI support for it to gwsmhg) that prevents me from agreeing.
>> Basically, I just don't see what it's offering and I especially worry that
>> it seems to permanently pollute the repository where as MQ keeps the patches
>> separate (except when they're applied).
>
> It offers a clean history of what happened when. Try to forget for a
> moment about the idea of a patch. Think instead about branches. I
> personally have a bunch of tweaks to my Hg install. I maintain these
> as a set of independent branches off of crew. When crew updates, I
> simply merge it into each of these branches. And I merge the heads of
> all these branches together again for my installed version. So this is
> my pgraph:
>
> @ rel
> |\
> | \
> | |\
> | | \
> | | |\
> o | | | bashcomp-meld
> | | | |
> | o | | hgrc-defaults-in-parentdirs
> |/ / /
> | o | transplant-merge-all
> | | |
> +---o graphlog-collapse-runs
> | |
> | o transplant-unless
> | |
> | o transplant-merges
> | |
> | o transplant-nochange
> |/
> o default
>
> I never think in terms of patches here, except when reviewing what a
> particular branch does (I want to see its cumulative effect against
> crew). But I keep the changes in separate branches so I can fix stuff
> in isolation when crew changes incompatibly, without possible
> side-effects from others of my changes. Incidentally, this is one
> reason why one might one to use qguard with mq - to test patches in
> isolation.
>
> So this is pbranch in "merge flow orchestration" mode. At any time, I
> know exactly what my installed version of hg looked like, can revert
> to it, can get meaningful diffs, etc. All with basically standard hg
> operations on my main repo. No need for versioned patch files and
> interdiff.
>
> Should I really want to get rid of the pbranch cruft again, I would
> simply reclone crew, apply my pdiffs to it, and drop the pbranch-repo.
> (Or, once it's done, use the proposed pfinish.) But so far, I saw no
> need for that. Some of my local patches were accepted upstream, so I
> simply merge them, resulting in an empty pdiff, and then close them. I
> keep my personal history.
>
>>> Where mq is far superior, though, is when the set of active patches
>>> needs to change at will (qguard).
>>
>> I never use this feature and struggle to imagine cases where it would be
>> useful. That's why (at the moment) both gquilt and gwsmhg ignore them and
>> probably will continue to do so unless I receive requests to add support for
>> them.
>
> See above.
>
>>> On the other hand, pbranch maintains a true graph of patch
>>> dependencies, whereas mq is linear (unless you count judicious use of
>>> qguard as a sort of graph management).
>>
>> I (mostly) only use linear patch series as I'm usually breaking up some
>> large change (e.g. adding plug in CPU schedulers to the Linux kernel) into
>> easily digestible (for a reviewer) chunks in an order that is (hopefully)
>> logical for the reviewer (and, at least, for myself).
>
> I have switched to pbranch for this, too. The reason here is: Imagine
> I make a change to one of the later patches. While doing so, I realize
> some of the changes should really go into an earlier patch, or a later
> patch, or even a new intermediate patch. With mq, this takes some
> judicious shuffling with qref -X/-I, qrecord, qpush/pop -f, etc. I
> more than once lost some of my changes due to mishandling mq while the
> changes were in transit to other patches. I hate that.
>
> With pbranch, I first commit what I did to my current patch. Only then
> do I shuffle parts of the changes around, knowing I have a safe base
> to return to. I guess there is a workable way to do this with mq too,
> like qref on the current patch for the safe base, then import
> --no-commit of the patch into earlier patches and revert all that's
> unneeded there, then qref, then update back to the first patch and
> qref again, resolving the resulting conflicts (ugh), etc.
>
> Same when upstream changes. I have a clearly defined safe base to
> return to if anything gets borked on the merge.
>
> For me, it boils down to pbranch doing things the hg way, using
> merge's and update's built-in merge logic when shuffling things
> around, whereas mq always has these patch rejects and stuff, that
> totally fall out of the normal workflow, don't get merge tool support,
> and can lead to loss of data.
>
> Maybe even deeper integration of mq with rebase could alleviate this.
> Or maybe moving away from the idea of patch files entirely and using
> rebase with multiple in-flight versions of csets. Shall think about
> this in a separate email.
>
> Anyhow, as you said before, mq has use cases where it's an excellent
> choice. I believe so has pbranch.
>
> [snip]
>
>> PS Have you had a chance to play with the pbranch interface in gwsmhg yet?
>> If so do you have any suggestions for improvement (other than adding a
>> decent graphical display of the dependency graph which is on my list albeit
>> at the end)?
>
> Yes. Although I do miss the graphical view. And I'm really more of a
> hgtk (TortoiseHg) guy, so since Peer is building pbranch support for
> that, I guess I'll stay with hgtk. Note, too, that startup time for
> gwsmhg for my local hg is hugely slower than for hgtk stat. You might
> want to look into that.

It also preloads a large chunk of history. Maybe I can make the size of
the chunk smaller (or even configurable).

When I last did timings, the great majority of gwsmhg's delays is due to
the time the hg commands take to run. This might be speeded up slightly
by importing Mercurial code and running the functions directly instead
of running hg commands but that has the disadvantage of a more dynamic
interface (meaning that matching versions of hg becomes a problem -- as
for hgtk refusing to install on Fedora 12 because it wanted hg-1.4 and
only hg-1.3.1 was available and pbranch not working on Fedora 12 at the
moment) -- and also raises potential data caching issues within
Mercurial. gwsmhg can't used cache data to make decisions because it
may be changed by the use of hg commands externally so the only caching
is that inherently present in display of the data. Because hg commands
don't have this concern I can't be certain that some caching of data
occurs within its code and this could be transferred to gwsmhg if I
import its code directly.

Another aspect that slows gwsmhg is the need to update all displayed
data when there is a POSSIBILITY that it has changed. I'm investigating
using pyinotify to improve this aspect but any solution would be
restricted to Linux versions.

Peter
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial