Re: Plans for Mercurial branches?
On 18/08/10 17:14, Ben Fritz wrote: On Aug 17, 4:56 pm, Matt Wozniskim...@drexel.edu wrote: Most users don't get their vim from source control at all - they get it from binaries or source provided by their distro. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. Keep in mind that in most opensource projects work that way - I don't think I've ever checked out code where the starting branch wasn't the main development branch. If you want an older version, it's easy to check out an old tag. With CVS or SVN, you'd always get the latest HEAD, there's no reason for Hg to be any different. I don't think I can top what Matt says here, I agree whole-heartedly. When I look at a new project, I personally expect the latest and greatest to be on the main trunk, unless there are spurious experimental branches. I expect that when I want to look at an old version, I will need to do something special. I expect that most users will either get pre-compiled binaries when they don't want the bleeding-edge stuff, or will be willing to do a little extra work to ensure a stable version. Also, the Mercurial documentation says that it is strongly recommended to use the default branch for the branch where active development is being done. This would mean the bleeding-edge latest of the greatest which receives the most pushes, not some stable branch which will be retired (possibly after some grace period during which it receives only security and stability updates) once the next release achieves sufficient stability. Maybe we could have a floating stable label that moves from time to time as new versions get used and tested, to limit the amount of thinking that goes into getting the latest stable build? In Mercurial that would be a tag i.e. a label applying to one changeset, but which can be moved by tagging a later changeset with the same tag. The tip tag is special in that it always means the changeset most recently added to the repository; other tags can be moved by an explicit hg tag followed by hg commit. Each changeset may have zero or more tags. For instance one may want to tag a certain changeset as both VERSION_9_5_RC1 and VERSION_9_5_RELEASE then if necessary a later changeset will be tagged VERSION_9_5_RC2 and VERSION_9_5_RELEASE, thus removing the release tag from the RC1 build. Then if the RC2 doesn't exhibit release-breaking buggy behaviour, it will stay as the 9.5 release build with no additional change to the repository. (I've seen this kind of thing happen recently while lurking in the #chatzilla channel at irc.mozilla.org, and a robot announced new tags being defined for SeaMonkey in the Mozilla comm-central hg repository.) Best regards, Tony. -- Politics is like coaching a football team. you have to be smart enough to understand the game but not smart enough to lose interest. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On 18/08/10 14:49, Xavier de Gaye wrote: On Wed, Aug 18, 2010 at 2:01 PM, James Vega wrote: On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote: I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. This would have worked just fine (as I had mentioned the first time it was brought up). This is not quite right. Attempting to merge vim72 into default, or default into vim72 (as with the following two sequences of commands) requires to manually solve many merge conflicts. # vim72 into default hg clone vim-master foobar cd foobar hg merge vim72 # default into vim72 hg clone vim-master foobar cd foobar hg update vim72 hg merge default The expected way to resolve the end of a branch's development cycle is to merge it back into its parent. This would have prevented the problem that Tony raised about the default branch now having two heads. Actually, having multiple heads in the same branch may be considered as not a problem. When we have local changes, after pulling from the official repository, in order to merge the new official changesets into our own local changes, we now have to run (wherehighest revision number is given by 'hg heads' for example): hg merge -rhighest revision number instead of previously with only one head: hg merge Xavier Also, with multiple heads in the current branch, the fetch extension cannot be used: instead of one command hg fetch --switch-parent you have to run three hg pull -u hg merge -r ab3fc5de6b49 hg commit -m 'merge for patchlevel 7.3.004' and the text for the latter two (or at least for the middle one) varies every time. Best regards, Tony. -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS I'm very probably wrong. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Saturday 21 August 2010 11:48:23 Tony Mechelynck wrote:
On 18/08/10 14:49, Xavier de Gaye wrote:
On Wed, Aug 18, 2010 at 2:01 PM, James Vega wrote:
On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar
wrote:
I think what would normally happen is to merge the
development branch back into the default branch. But just
like the problems you have now, I suspect that migth not
work very well.
This would have worked just fine (as I had mentioned the
first time it was brought up).
This is not quite right. Attempting to merge vim72 into
default, or default into vim72 (as with the following two
sequences of commands) requires to manually solve many merge
conflicts.
# vim72 into default
hg clone vim-master foobar
cd foobar
hg merge vim72
# default into vim72
hg clone vim-master foobar
cd foobar
hg update vim72
hg merge default
The expected way to resolve the end of a
branch's development cycle is to merge it back into its
parent. This would have prevented the problem that Tony
raised about the default branch now having two heads.
Actually, having multiple heads in the same branch may be
considered as not a problem. When we have local changes,
after pulling from the official repository, in order to
merge the new official changesets into our own local
changes, we now have to run (wherehighest revision number
is given by 'hg heads' for example):
hg merge -rhighest revision number
instead of previously with only one head:
hg merge
Xavier
Also, with multiple heads in the current branch, the fetch
extension cannot be used: instead of one command
hg fetch --switch-parent
you have to run three
hg pull -u
hg merge -r ab3fc5de6b49
hg commit -m 'merge for patchlevel 7.3.004'
and the text for the latter two (or at least for the middle
one) varies every time.
i've got a bash script that's been working for me for several
days now to simplify the merge -- i call it 'cs' and i think
changeset when i use it:
#!/bin/bash
# changeset
cd ~/.build/hgvim/vim
hg heads | awk -f ../lft.awk
where lft.awk contains:
# look for tip
/^changeset/ { cs = $0 }
/tag: tip/ {
split(cs, csa, /:/)
csn = csa[2]
gsub(/ /, , csn)
print csn
}
then to merge i can type
u2 `cs`
where u2 contains:
#!/bin/bash
# u2
cd ~/.build/hgvim/vim
date '+%Y-%b-%d %H:%M' 21 | tee -a ../update.log
echo about to hg merge $@../update.log
hg merge $@ 21| tee -a ../update.log
dsh | tee -a ../update.log
(and dsh just makes dashes)
i had to modify 'cs' recently when the wanted changeset no
longer contained both the tip and vim73 tags, and it may
change again soon, but this is working for me now and avoids
copying those horrible changeset ids (actually uses the
4-digit local prefix to the full id, which merge is fine with)
this is all so new and evolving i still like to run heads and
'cs' to verify it is naming the changeset i deem relevant
before i attempt using it to merge, and i recommend anyone
else using it do the same, at least until things settle down
and get a little more predictable
sc
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Saturday 21 August 2010 11:48:23 Tony Mechelynck wrote: On 18/08/10 14:49, Xavier de Gaye wrote: On Wed, Aug 18, 2010 at 2:01 PM, James Vega wrote: On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote: I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. This would have worked just fine (as I had mentioned the first time it was brought up). This is not quite right. Attempting to merge vim72 into default, or default into vim72 (as with the following two sequences of commands) requires to manually solve many merge conflicts. # vim72 into default hg clone vim-master foobar cd foobar hg merge vim72 # default into vim72 hg clone vim-master foobar cd foobar hg update vim72 hg merge default The expected way to resolve the end of a branch's development cycle is to merge it back into its parent. This would have prevented the problem that Tony raised about the default branch now having two heads. Actually, having multiple heads in the same branch may be considered as not a problem. When we have local changes, after pulling from the official repository, in order to merge the new official changesets into our own local changes, we now have to run (wherehighest revision number is given by 'hg heads' for example): hg merge -rhighest revision number instead of previously with only one head: hg merge Xavier Also, with multiple heads in the current branch, the fetch extension cannot be used: instead of one command hg fetch --switch-parent you have to run three hg pull -u hg merge -r ab3fc5de6b49 hg commit -m 'merge for patchlevel 7.3.004' and the text for the latter two (or at least for the middle one) varies every time. i've also got a [bash] script to merge -- i feel it overkill to repeat the commit message as tony is doing here, but i've coded it to allow me to specify a different message if i want to -- i call it 'u3': #!/bin/bash # u3 cd ~/.build/hgvim/vim dt=`date '+%Y-%b-%d %H:%M'` echo $dt ../update.log if [ $# -eq 0 ]; then echo about to hg commit ../update.log hg commit -m $dt -- updates from bram 21 | tee -a ../update.log else echo about to hg commit $@ ../update.log hg commit $@ 21 | tee -a ../update.log fi dsh ../update.log as you may guess, my first pull i call 'u', so for me a simple update is as simple as u, u2 `cs`, u3 sc -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Sat, Aug 21, 2010 at 6:48 PM, Tony Mechelynck wrote: On 18/08/10 14:49, Xavier de Gaye wrote: Actually, having multiple heads in the same branch may be considered as not a problem. When we have local changes, after pulling from the official repository, in order to merge the new official changesets into our own local changes, we now have to run (wherehighest revision number is given by 'hg heads' for example): hg merge -rhighest revision number instead of previously with only one head: hg merge Also, with multiple heads in the current branch, the fetch extension cannot be used: instead of one command hg fetch --switch-parent you have to run three hg pull -u hg merge -r ab3fc5de6b49 hg commit -m 'merge for patchlevel 7.3.004' and the text for the latter two (or at least for the middle one) varies every time. You may also run: hg pull hg merge -r tip hg commit -m 'Automated merge with http://vim.googlecode.com/hg/' Nothing varies in the above three statements, and these statements can go in a 'my_fetch.sh' script. The fetch extension has been implemented so as to emulate the behavior of 'git pull', for people familiar with git I guess. In git, you pull. In mercurial you pull, then merge or update or wait until a more appropriate time. Your choice. Mercurial looks more flexible in this matter. I don't see it as a problem. Xavier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Saturday 21 August 2010 15:52:09 Xavier de Gaye wrote: On Sat, Aug 21, 2010 at 6:48 PM, Tony Mechelynck wrote: On 18/08/10 14:49, Xavier de Gaye wrote: Actually, having multiple heads in the same branch may be considered as not a problem. When we have local changes, after pulling from the official repository, in order to merge the new official changesets into our own local changes, we now have to run (wherehighest revision number is given by 'hg heads' for example): hg merge -rhighest revision number instead of previously with only one head: hg merge Also, with multiple heads in the current branch, the fetch extension cannot be used: instead of one command hg fetch --switch-parent you have to run three hg pull -u hg merge -r ab3fc5de6b49 hg commit -m 'merge for patchlevel 7.3.004' and the text for the latter two (or at least for the middle one) varies every time. You may also run: hg pull hg merge -r tip hg commit -m 'Automated merge with http://vim.googlecode.com/hg/' Nothing varies in the above three statements, and these statements can go in a 'my_fetch.sh' script. unless and until runtime/doc/tags needs a commit, in which case you'll need an extra commit between the pull and the merge i keep thinking it should be easy to write an expect script to test for merge success and automating that, but i'm too new to expect for it to be easy for me sc -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On 22/08/10 00:30, Benjamin R. Haskell wrote:
On Sat, 21 Aug 2010, Xavier de Gaye wrote:
On Sat, Aug 21, 2010 at 6:48 PM, Tony Mechelynck wrote:
On 18/08/10 14:49, Xavier de Gaye wrote:
Actually, having multiple heads in the same branch may be
considered as not a problem. When we have local changes, after
pulling from the official repository, in order to merge the new
official changesets into our own local changes, we now have to run
(wherehighest revision numberis given by 'hg heads' for
example):
hg merge -rhighest revision number
instead of previously with only one head:
hg merge
Also, with multiple heads in the current branch, the fetch
extension cannot be used: instead of one command
hg fetch --switch-parent
you have to run three
hg pull -u
hg merge -r ab3fc5de6b49
hg commit -m 'merge for patchlevel 7.3.004'
and the text for the latter two (or at least for the middle one)
varies every time.
You may also run:
hg pull
hg merge -r tip
hg commit -m 'Automated merge with http://vim.googlecode.com/hg/'
Nothing varies in the above three statements, and these statements can
go in a 'my_fetch.sh' script.
This seems overly complicated for one of the most common things one does
with a repository. (get changes from upstream)
Isn't this essentially what the fetch extension does? (So the above
becomes: hg fetch) Or was this not working when there were two heads?
hg fetch does that without the -r tip switch to merge, failing if the
merge doesn't see exactly two heads (one with local changes and one
newly pulled) on that branch. If the remote master repo has two heads
for the branch, it fails as soon as you have local changes (as I have in
.hgignore and src/feature.h).
The fetch extension has been implemented so as to emulate the behavior
of 'git pull', for people familiar with git I guess. In git, you pull.
In mercurial you pull, then merge or update or wait until a more
appropriate time. Your choice. Mercurial looks more flexible in this
matter. I don't see it as a problem.
Actually, it seems like hg fetch (pull in new changes, merge if needed)
is roughly equivalent to git pull (fetch new changes, merge if needed).
So, confusingly:
hg pull ~= git fetch
hg fetch ~= git pull
In Gitopia, you fetch changes from the remote server, then pull them
into your local work. In Mercurialand, you pull changes from the remote
server and then fetch(?) them into your repository. (My preferred
nomenclature bias might be evident, here.)
hg fetch ~= hg pull hg merge hg commit -m Automated merge from
${paths.default}
In Mercurialand, you pull new metadata into your repository then locally
update your working directory. Or maybe merge outstanding topological
branches then commit the result. Fetching is a nondefault extension,
roughly equivalent to pull+merge+commit, chiefly (IMHO) for use on
pull-only repositories with local changes. (By pull-only I mean that you
won't need to push from them.)
Also, in Mercurialand (and assuming the necessary privileges are set) if
repositories A and B are related (by one being a clone of the other, or
both clones of a 3rd one) pushing and pulling are reciprocal operations:
if user A pushes from his repo to to repository B, or user B pulls from
repository A, the result is supposed to be the same.
Best regards,
Tony.
--
They told me I was gullible ... and I believed them!
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote: I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. This would have worked just fine (as I had mentioned the first time it was brought up). The expected way to resolve the end of a branch's development cycle is to merge it back into its parent. This would have prevented the problem that Tony raised about the default branch now having two heads. The vim73 head would still exist, but it could be marked as a closed branch if you didn't want it to show up in the default hg heads view. As such, people could still hg up vim73 to get the original version with no patches but it wouldn't clutter the default view. Speaking of extra heads, would it make sense to mark the spurious vim head as closed so it doesn't show up in the default view? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Plans for Mercurial branches?
On Wed, Aug 18, 2010 at 2:01 PM, James Vega wrote: On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote: I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. This would have worked just fine (as I had mentioned the first time it was brought up). This is not quite right. Attempting to merge vim72 into default, or default into vim72 (as with the following two sequences of commands) requires to manually solve many merge conflicts. # vim72 into default hg clone vim-master foobar cd foobar hg merge vim72 # default into vim72 hg clone vim-master foobar cd foobar hg update vim72 hg merge default The expected way to resolve the end of a branch's development cycle is to merge it back into its parent. This would have prevented the problem that Tony raised about the default branch now having two heads. Actually, having multiple heads in the same branch may be considered as not a problem. When we have local changes, after pulling from the official repository, in order to merge the new official changesets into our own local changes, we now have to run (where highest revision number is given by 'hg heads' for example): hg merge -r highest revision number instead of previously with only one head: hg merge Xavier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Aug 17, 4:56 pm, Matt Wozniski m...@drexel.edu wrote: Most users don't get their vim from source control at all - they get it from binaries or source provided by their distro. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. Keep in mind that in most opensource projects work that way - I don't think I've ever checked out code where the starting branch wasn't the main development branch. If you want an older version, it's easy to check out an old tag. With CVS or SVN, you'd always get the latest HEAD, there's no reason for Hg to be any different. I don't think I can top what Matt says here, I agree whole-heartedly. When I look at a new project, I personally expect the latest and greatest to be on the main trunk, unless there are spurious experimental branches. I expect that when I want to look at an old version, I will need to do something special. I expect that most users will either get pre-compiled binaries when they don't want the bleeding-edge stuff, or will be willing to do a little extra work to ensure a stable version. Maybe we could have a floating stable label that moves from time to time as new versions get used and tested, to limit the amount of thinking that goes into getting the latest stable build? -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote: Xavier de Gaye wrote: The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). ... Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. Assume that on doing the first branching last may, the reverse had been done instead, that is: . the vim73 release is developed on the main branch (the 'default' NamedBranch) . creation of a 'vim72' NamedBranch where the critical patches of the main branch (the 'default' NamedBranch) are retrofited as vim72 patches . the 'vim73' NamedBranch does not exist What would have changed: . no need to 'hg update vim73' when the branch was created (as most of us probably did at this time) . no need to 'hg update default' now (without forgetting to do first a 'hg pull'), once the vim73 release is done What are the drawbacks of the above scheme ? Xavier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On 17 August 2010 13:11, Xavier de Gaye wrote: On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote: Xavier de Gaye wrote: The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). ... Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. Assume that on doing the first branching last may, the reverse had been done instead, that is: . the vim73 release is developed on the main branch (the 'default' NamedBranch) . creation of a 'vim72' NamedBranch where the critical patches of the main branch (the 'default' NamedBranch) are retrofited as vim72 patches . the 'vim73' NamedBranch does not exist What would have changed: . no need to 'hg update vim73' when the branch was created (as most of us probably did at this time) . no need to 'hg update default' now (without forgetting to do first a 'hg pull'), once the vim73 release is done What are the drawbacks of the above scheme ? It would have made life easier for me with maintaining the Git repository. Renaming the vim73 branch default lead to problems as I outlined in a recent post. Had the development of vim73 taken place on the default branch I would have had no problems. I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). Björn -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
Björn Winckler wrote: On 17 August 2010 13:11, Xavier de Gaye wrote: On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote: Xavier de Gaye wrote: The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). ... Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. Assume that on doing the first branching last may, the reverse had been done instead, that is: . the vim73 release is developed on the main branch (the 'default' NamedBranch) . creation of a 'vim72' NamedBranch where the critical patches of the main branch (the 'default' NamedBranch) are retrofited as vim72 patches . the 'vim73' NamedBranch does not exist What would have changed: . no need to 'hg update vim73' when the branch was created (as most of us probably did at this time) . no need to 'hg update default' now (without forgetting to do first a 'hg pull'), once the vim73 release is done What are the drawbacks of the above scheme ? It would have made life easier for me with maintaining the Git repository. Renaming the vim73 branch default lead to problems as I outlined in a recent post. Had the development of vim73 taken place on the default branch I would have had no problems. I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). In my opinion the default branch should contain the stable version. Most users would sync there once in a while to update their Vim. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. -- From know your smileys: %-)After staring at screen for 15 hours /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Tue, Aug 17, 2010 at 5:26 PM, Bram Moolenaar wrote: Björn Winckler wrote: I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). In my opinion the default branch should contain the stable version. Most users would sync there once in a while to update their Vim. Most users don't get their vim from source control at all - they get it from binaries or source provided by their distro. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. Keep in mind that in most opensource projects work that way - I don't think I've ever checked out code where the starting branch wasn't the main development branch. If you want an older version, it's easy to check out an old tag. With CVS or SVN, you'd always get the latest HEAD, there's no reason for Hg to be any different. Just my $0.02 ~Matt -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Sun, Aug 15, 2010 at 10:19 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
The 'vim73' branch can be given the name of the 'default' branch with
the 'hg branch --force default' command after the 'default' branch is
named 'vim72' with the 'hg branch vim72' command (both followed by
commit).
...
Now that I'm ready to make vim73 the default branch, it occurs to me
that when I do this, doing hg update vim73 will stop working.
What I would like to do is keep the vim73 label on the branch, but
make it the default one.
So currently:
hg clone ... gives you the default branch, Vim 7.2.1234
hg update vim73 switches to Vim 7.3
What I would like to get:
hg clone ... gives you the default branch, Vim 7.3.001
hg update vim73 stays on the default branch
I understand that 'branch' is an attribute of a changeset with a
single value ('default' or 'vim73', but not both), so that it is not
possible to have 'hg update default' and 'hg update vim73' give the
same result.
hg update vim72 switches to Vim 7.2.1234
Is that possible? Or does making vim73 the default branch always have
the result that switching to the vim73 branch stops working?
An acceptable alternative would be that the default branch has the
latest version, including patches, while vim73 is plain 7.3, no patches.
'vim73 is plain 7.3, no patches' is what happens when the 'vim73'
branch is renamed the 'default' branch after the vim73 release have
been made.
Attached is a shell script that creates a repository in a new
'branch_test' directory and runs a sequence of hg commands that
reproduce what happens when branches are renamed this way. After the
script is run and cloning the repository, the cloned repo behaves as
in the acceptable alternative above.
Xavier
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
hg_branch_test.sh
Description: Bourne shell script
Re: Plans for Mercurial branches?
BTW the Graph log extension is easy to setup and very handy to follow branches in a mercurial repository and to see where is the parent of the working directory (indicated by '@' in the graph) See http://mercurial.selenic.com/wiki/GraphlogExtension Xavier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
Xavier de Gaye wrote:
The 'vim73' branch can be given the name of the 'default' branch with
the 'hg branch --force default' command after the 'default' branch is
named 'vim72' with the 'hg branch vim72' command (both followed by
commit).
...
Now that I'm ready to make vim73 the default branch, it occurs to me
that when I do this, doing hg update vim73 will stop working.
What I would like to do is keep the vim73 label on the branch, but
make it the default one.
So currently:
hg clone ... gives you the default branch, Vim 7.2.1234
hg update vim73 switches to Vim 7.3
What I would like to get:
hg clone ... gives you the default branch, Vim 7.3.001
hg update vim73 stays on the default branch
I understand that 'branch' is an attribute of a changeset with a
single value ('default' or 'vim73', but not both), so that it is not
possible to have 'hg update default' and 'hg update vim73' give the
same result.
hg update vim72 switches to Vim 7.2.1234
Is that possible? Or does making vim73 the default branch always have
the result that switching to the vim73 branch stops working?
An acceptable alternative would be that the default branch has the
latest version, including patches, while vim73 is plain 7.3, no patches.
'vim73 is plain 7.3, no patches' is what happens when the 'vim73'
branch is renamed the 'default' branch after the vim73 release have
been made.
Attached is a shell script that creates a repository in a new
'branch_test' directory and runs a sequence of hg commands that
reproduce what happens when branches are renamed this way. After the
script is run and cloning the repository, the cloned repo behaves as
in the acceptable alternative above.
Thanks. The shell script is especially useful to see what really
happens.
So it's not possible to have two branch names for the same version. I
think what you have done here is most likely the best solution. The
only other alternative I heard is merging the vim73 branch back into
default, but that has more chances of going wrong. And I don't really
seen an advantage, since all changes in the 7.2 branch (called default
until now) have been included in 7.3.
--
hundred-and-one symptoms of being an internet addict:
91. It's Saturday afternoon in the middle of May and you
are on computer.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
Xavier de Gaye wrote: On Sun, May 23, 2010 at 12:38 PM, Bram Moolenaar wrote: ... When 7.3 is released it will become the default branch. =A0How this is done I don't know. ... The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). A simple test made on a fake repo with 'default' and 'vim73' branches (same as in the current vim repo) shows this result after that is done: $ hg branches default 5:ce5266650699 vim72 4:d5bb6abbab9a vim73 3:90078dbe59dd (inactive) Changeset '3:90078dbe59dd' is the tip of the vim73 branch before it is renamed to 'default'. Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. What I would like to do is keep the vim73 label on the branch, but make it the default one. So currently: hg clone ... gives you the default branch, Vim 7.2.1234 hg update vim73 switches to Vim 7.3 What I would like to get: hg clone ... gives you the default branch, Vim 7.3.001 hg update vim73 stays on the default branch hg update vim72 switches to Vim 7.2.1234 Is that possible? Or does making vim73 the default branch always have the result that switching to the vim73 branch stops working? An acceptable alternative would be that the default branch has the latest version, including patches, while vim73 is plain 7.3, no patches. -- hundred-and-one symptoms of being an internet addict: 80. At parties, you introduce your spouse as your service provider. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On 15/08/10 22:57, Tony Mechelynck wrote: On 15/08/10 22:19, Bram Moolenaar wrote: Xavier de Gaye wrote: On Sun, May 23, 2010 at 12:38 PM, Bram Moolenaar wrote: ... When 7.3 is released it will become the default branch. =A0How this is done I don't know. ... The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). A simple test made on a fake repo with 'default' and 'vim73' branches (same as in the current vim repo) shows this result after that is done: $ hg branches default 5:ce5266650699 vim72 4:d5bb6abbab9a vim73 3:90078dbe59dd (inactive) Changeset '3:90078dbe59dd' is the tip of the vim73 branch before it is renamed to 'default'. Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. What I would like to do is keep the vim73 label on the branch, but make it the default one. So currently: hg clone ... gives you the default branch, Vim 7.2.1234 hg update vim73 switches to Vim 7.3 What I would like to get: hg clone ... gives you the default branch, Vim 7.3.001 hg update vim73 stays on the default branch hg update vim72 switches to Vim 7.2.1234 Is that possible? Or does making vim73 the default branch always have the result that switching to the vim73 branch stops working? An acceptable alternative would be that the default branch has the latest version, including patches, while vim73 is plain 7.3, no patches. I think it's your acceptable alternative: if you make the default branch point to the latest 7.3 build -- maybe by hg update default hg --config ui.merge=internal:other merge -r vim73 (but watch out for resurrected files if you do that) then (IIUC) hg update vim73 will forever give you the last 7.3 changeset before the merge. You may thereafter create a tag (pointing to one revision) or a branch (pointing to one revision and all its children excluding other branches) so that hg update vim72 would point to 7.2.446 or its latest 7.2 descendant if any. For a branch you may need to create a new changeset with no changes, I'm not sure. Or you may wait until 7.2.447 if any and use a --branch argument in the commit for that changeset. Best regards, Tony. Oops, creating a branch is a separate transaction, not an option of hg commit. Best regards, Tony. -- Cable is not a luxury, since many areas have poor TV reception. -- The mayor of Tucson, Arizona, 1989 -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
Björn Winckler wrote: I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. When 7.3 is released it will become the default branch. How this is done I don't know. There were some problems when I used hg rebase on the vim73 branch, now it's no longer possible to merge directly from the default branch into the vim73 branch. I don't know if the other way around would still work. Or that we need to use export + import. -- From know your smileys: ...---... SOS /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On 23 May 2010 12:38, Bram Moolenaar wrote: Björn Winckler wrote: I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. When 7.3 is released it will become the default branch. How this is done I don't know. There were some problems when I used hg rebase on the vim73 branch, now it's no longer possible to merge directly from the default branch into the vim73 branch. I don't know if the other way around would still work. Or that we need to use export + import. I don't know how to do this either -- from what I can tell you will have to rewrite history in some way (e.g. export+import). On that topic, will the history of the default branch never be rewritten (no rebase, etc.)? If so, I will merge the MacVim branch against the default branch (and probably keep a topic branch that merges against vim73). Björn -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On 23/05/10 15:30, björn wrote: On 23 May 2010 12:38, Bram Moolenaar wrote: Björn Winckler wrote: I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. When 7.3 is released it will become the default branch. How this is done I don't know. There were some problems when I used hg rebase on the vim73 branch, now it's no longer possible to merge directly from the default branch into the vim73 branch. I don't know if the other way around would still work. Or that we need to use export + import. I don't know how to do this either -- from what I can tell you will have to rewrite history in some way (e.g. export+import). On that topic, will the history of the default branch never be rewritten (no rebase, etc.)? If so, I will merge the MacVim branch against the default branch (and probably keep a topic branch that merges against vim73). Björn I guess this kind of problem is why Mercurial recommends that the default branch always be the branch undergoing active development, i.e., usually not the current stable branch but the experimental branch which will someday become the next release. Then when work starts on a further release, the current release is branched off, and the work-in-progress for the new release happens on the default without affecting the stable release which has just received a branch name. OTOH the branched-off release(s) may still receive security stability updates for some time (usually at a decreasing rate) and then die (be closed in Mercurial language). Mercurial is based on invariant history, so in principle (with a few exceptions such as hg rollback) what has been done cannot be undone, and too bad for the (l)user if he goofed and doesn't see it at once. If we someday want that what is now the default branch become a vim72 branch while the current vim73 branch should become a new default, it may be quite hard to achieve. Maybe with the transplant extension and/or the experimental hg rebase --detach (available only in the development version of the rebase extension)... Now if only there were a few more examples and explanations in that Mercurial documentation... Maybe it will be simpler to go on with the vim73 branch, and someday let the so-called default branch die, when Vim 7.2 will be at EOL? Or else, maybe (but I don't know if it's allowed) hg branch -f default to force the current (vim73) branch to become the default, obscuring the earlier default? Maybe after hg branch vim72 on the current default, so that work on Vim 7.2 can still continue? Best regards, Tony. -- Prostitution is the only business where you can go into the hole and still come out ahead. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
Björn Winckler wrote: On 23 May 2010 12:38, Bram Moolenaar wrote: Björn Winckler wrote: I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. When 7.3 is released it will become the default branch. How this is done I don't know. There were some problems when I used hg rebase on the vim73 branch, now it's no longer possible to merge directly from the default branch into the vim73 branch. I don't know if the other way around would still work. Or that we need to use export + import. I don't know how to do this either -- from what I can tell you will have to rewrite history in some way (e.g. export+import). On that topic, will the history of the default branch never be rewritten (no rebase, etc.)? If so, I will merge the MacVim branch against the default branch (and probably keep a topic branch that merges against vim73). I have been told in a Mercurial maillist that hg rebase must not be used for changes that have been pushed. Thus it's safe to assume the default branch will keep it's history. -- % cat /usr/include/life.h void life(void); /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Plans for Mercurial branches?
On Sun, May 23, 2010 at 12:38:10PM +0200, Bram Moolenaar wrote: Björn Winckler wrote: I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. When 7.3 is released it will become the default branch. How this is done I don't know. There were some problems when I used hg rebase on the vim73 branch, now it's no longer possible to merge directly from the default branch into the vim73 branch. I don't know if the other way around would still work. Merging vim73 into default should work fine, and it currently does. I tried it earlier today. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: Plans for Mercurial branches?
On 2010-05-23, Bram Moolenaar wrote: Björn Winckler wrote: I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. When 7.3 is released it will become the default branch. How this is done I don't know. There were some problems when I used hg rebase on the vim73 branch, now it's no longer possible to merge directly from the default branch into the vim73 branch. I just did this and it seemed to work fine. Specifically, I cloned the vim repo, which was at changeset a8afba7027ae at the time, and merged the 7.2.437 patch to the vim73 branch as follows. hg update vim73 hg merge default hg ci I had to manually merge the file that contains the patch list, version.c, I think, but that was easy using vimdiff. You should be able to merge each Vim 7.2 patch to the vim73 branch as it comes along. Regards, Gary -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Plans for Mercurial branches?
Hi, I was wondering what the plans for the Mercurial branches are once 7.3 is finished. Will vim73 be merged into default at some point, or will there be one giant vim73 patch applied to default (making all changesets in the vim73 branch into a patch) and vim73 will be left, or ...? I am wondering because I am in the process of changing the MacVim repo to use the Vim Mercurial repo as upstream instead of the svn repo. This is to allow me to make an informed decision as to which branch to merge my own macvim branch against. Thanks, Björn -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
