|Deletions are marked like this.||Additions are marked like this.|
|Line 80:||Line 80:|
|* nobody: https://launchpad.net/products/xrms/trunk [[BR]] :pserver:email@example.com:/cvsroot/xrms/ xrms [[BR]] [[[Date(2006-09-29T21:20:41Z)]]]||* nobody: https://launchpad.net/products/xrms/trunk [[BR]] :pserver:firstname.lastname@example.org:/cvsroot/xrms/ xrms [[BR]] [[[Date(2006-09-29T21:20:41Z)]]]|
This page tracks requests for actions from the vcs-imports operator.
To request an import, please:
- Create a product in Launchpad and set the source details to the CVS or Subversion repository you wish to have imported. In particular
- Add a request on this page, with the name of your launchpad account so I can find your email.
Note that we only do imports of MAIN branches on CVS (the form will have to be updated to remove the "branch" field) and trunk branches on Subversion.
We will handle your request and keep you informed of progress or issues. You can contact the vcs-imports operator: ddaa in #launchpad on irc.freenode.net.
Template to request an import:
Imports that need intervention from the vcs-imports operator.
Imports being processed.
Better REPLACE support
Imports that have failed and that need better support for replaced files.
Initial revision is a move
[https://launchpad.net/bugs/58029 Bug 58029].
It appears that when a svn branch is created by a move (copy + delete), the initial imported revision is empty, which causes a failure on the first revision that tries to modify a pre-existing file.
In the case of the katapult import (svn://anonsvn.kde.org/home/kde/trunk/extragear/utils/katapult), the branch is created at revision 521764 by moving from /trunk/playground/utils/katapult:521763. The initial revision of the bzr import is an empty tree.
[https://launchpad.net/people/mez Mez]: https://launchpad.net/products/katapult/mainstream BR svn://anonsvn.kde.org/home/kde/trunk/extragear/utils/katapult BR [Date(2006-08-28T15:43:43Z)]
On changeset 576 BR This is the initial revision of the branch, it is a complicated combination of renames and file modifications, consolidating a trunk branch out of multiple parts. Some of the moved files are properly imported, but one of the files which is copied _and_ modified in this revision was not imported, and causes a failure when trying to apply the modification. BR 'action': 'M', 'path': u'/trunk/test/test', 'copyfrom_path': None, 'copyfrom_revision': None BR RuntimeError: file test/test not present in tree
On changeset 917 BR IOError: [Errno 2] No such file or directory: u'/srv/importd.ubuntu.com/botslave/series-000012c3/bzrworking/locale/,,new.0.646637021358.template.po'
Illegal file name
on changeset MAIN.4167: BR CRITICAL: requested checkout of reporoot '/cvsroot/xrms', file 'xrms/include/adodb/pear/Attic/readme.Auth.txt', revision '22.214.171.124' BR CRITICAL: log of checkout responses follow. BR CRITICAL: "E cvs checkout: cannot find module BR `xrms/include/adodb/pear/Attic/readme.Auth.txt' - ignored\n" BR CRITICAL: 'error \n'
cscvs wants to create a filler changeset 1.1->126.96.36.199 for include/adodb/pear/readme.Auth.txt, but there is no revision 188.8.131.52 for that file. The cvs rlog shows revision 1.1 (branches: 1.1.1) used in changeset MAIN.915, revision 184.108.40.206, not used by cscvs. The cvs log header for that file reads "head: 1.1" and "branch: 1.1.1".
- In other words, it might be a weird case of default branch setting that exposes a bug in the cscvs filler changeset logic.
Imports that have failed, for an unknown reasons, and whose failure do not fall in a clear group of similar failures.
REPORT failed on path with bang
Imports that failed to do REPORT on a path with a bang. I do not know what that means, but there's clearly a pattern.
r29 appears to include a directory move of trunk/epm/loaders to trunk/epm/backends. The /!svn/bc/28/trunk/epm/backends path looks like it'd refer to "trunk/epm/backends in r28", which didn't exist.
Tried to get inexistant previous revision
Imports that failed on changeset N while trying to access revision N-1 for a file, because that file does not exist in revision N-1.
Failed to fork, memory error
Some large imports fail to os.fork() (when spawning gpg to sign a revision) with "OSError: [Errno 12] Cannot allocate memory". It's not clear why that happen, since Linux should overcommit memory up to 50x (the value of /proc/sys/vm/overcommit_ratio) and allow large processes like cscvs to spawn small processes like gpg.
- On changeset changeset 5343
- On changeset MAIN.15819
- On changeset 7