Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit : > > In preparation for the hg switch, I would recommend that, if you have > > any feature branches managed with svnmerge, you sync them with the py3k > > branch before we switch. That way, it will make it easier to "bridge > > the gap" when you create a new repository for your work after the > > switch (the svnmerge information isn't retained in the converted repo). > > Is that really going to work? I.e. will Mercurial be able to merge from > default to one of the feature branches? If so, what will be the > procedure? What would be the exact steps to try this out on the PEP 382 > branch (say)? I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-features It doesn't cover importing work from SVN, but it should be as simple as "apply your current patch" where the text says "You can now work on your feature". A caveat of these instructions is that pushing a whole cpython-based repo will be quite slow unless you have a large upload bandwidth (most users have asymmetric connections). So we would like to offer a special command for committers to make a clone of a repository *from the server, to the server*. In my current prototype this is spelled as: ssh hg at hg.python.org clone <srcrepo> <dstrepo> for example: ssh hg at hg.python.org clone cpython features/pep-382 where "features/pep-382" will be a new repo on hg.python.org cloned from the cpython repo on hg.python.org. Meaning no heavy network transfer occurs. Then you clone the dest repo and the only changesets will have to push will be those representing your own work. If you think the "remote clone" trick above is good enough, I'll publicize it in the devguide. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4