I wrote:
Ulterior motive: It would make a lot of sense, and certainly make my
life easier, if the MacVim repository could be based on the Vim
repository. Of course, ideally I'd love to see MacVim using hg, too, but
with the help of that extension above, it could continue using git and
still use the official Vim repository, plus I could maintain my own hg
repository with the patches I regularly apply, test, and so on.
Bjorn, how does this sound to you? I know it could be a challenge to set
it up, particularly preserving old MacVim history and the way it
interacts with old Vim history, but would you be willing to pursue this?
I'm willing to help with that initial conversion.
Bjorn wrote:
I'm waiting until things "settle".
I agree this is wise. I think we need only wait until we're sure that
Mercurial will continue, i.e. once vim_dev have tried it out a bit more
thoroughly and Bram decides to publish its existence more widely. We
needn't wait until CVS is dropped.
Bjorn wrote:
If Bram decides to continue with the hg repo I was considering
switching to hg for MacVim as well. For me it makes more sense to
just follow Bram's lead -- I only started with the git repo because of
the lack of other options at that time (I wanted to use _some_
distributed vcs but I don't really care that much about which
particular one to use).
That would suit me!
Bjorn wrote:
Importing the current MacVim history to hg is something I don't look
forward to however, I'll take any help I can get with this task. If
it is possible to simply change the upstream source for my repo to the
hg repo (instead of the svn repo that I currently pull from) and stick
with git, then I might consider that instead. As I said though: I'm
not in a hurry to change the current repo.
It wouldn't be as simple as changing the upstream repo. The repo would
need to be converted/rebuilt.
Jiang wrote:
I am also interested in maintaining a git repository based on vim hg
repo, either directly or indirectly. Currently both mine (vim-cocoa)
and MacVim repo are based on the Subversion repo at sf.net, which is
synced manually with git-svn, so I am also curious about the technical
approach to switch from git-svn to this hg or git repo set up by
upstream.
I haven't searched the web for potential solutions to this problem, yet,
but was thinking something along these lines would work if nothing else:
- get an hg version of the MacVim git repo
- clone the Vim hg repo
- initialise some kind of table to map equivalent revisions in the two
repos
- identify (using a script somehow, most likely) revisions in the two
repos that are nominally equivalent, i.e. vim upstream revisions that
are the same patchlevel
- possibly identify runtime file updates somehow
- for each unidentified revision in the MacVim repo:
- check out a working copy
- find the parents
- using the table, set the parents of the working copy of the Vim
repo to the equivalent revisions
- copy the contents of the MacVim working copy to the Vim working
copy
- check in the Vim working copy with the appropriate commit message
from the MacVim revision
- add the new changeset to the map of equivalent revisions
- tag appropriately
- push losslessly to a git repo if desired
This approach I think has a few advantages
- by copying working copies rather than playing games with diffs, we are
assured that the revisions are content-wise the same in the new repo
as the MacVim repo
- MacVim revisions that aren't merges with Vim revisions will have
different hashes, but the same diffs, so MacVim history is essentially
maintained
- Vim history is unaltered from the official repo
There are some issues that require further thought or are a bit unknown
- revisions that are Vim-MacVim merges could end up with a bunch of
changes that shouldn't really be there, particulary regarding runtime
files, if the MacVim repo's idea about a particular patchlevel is
different to the Vim repo's idea about the same
- any named branches, octopus merges, or other somewhat git-specific
things could pose challenges
- how to deal with runtime files needs to be considered; I suspect
eliminating them from the MacVim history, except for tagged snapshots,
would be a sufficient solution, and a good compromise between having a
lot of spurious changes bloating the repo size, but keeping accurate
history; after all, Vim is often run with different runtime files to
its source code, and does just fine on the whole
Naturally, I'm open to comments on this, or to someone else more in the
know doing it rather than me! I am willing to put time into something
like this, though; I feel it would help both the community and me.
Ben.
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
