openvpn uses svn:externals
|Deletions are marked like this.||Additions are marked like this.|
|Line 26:||Line 26:|
* [https://launchpad.net/people/kamion kamion]: https://launchpad.net/products/partman-auto-lvm/trunk [[BR]]
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.
Imports that are currently failing, and for which no fix is currently being worked on.
[svn] missing uri-encoding
cscvs uses the svn_client API to libsvn to retrieve data (on Date(2006-11-09T14:31:29Z)), but does not correctly uri-encode locations. So file names that contain characters that must be escaped cause import failures.
[cvs] failed to open the modules file
cscvs needs to read the modules file to ignore configs (aka externals, nested trees).
$ cvs -d :pserver:guest:firstname.lastname@example.org:/cvs co -c cvs [checkout aborted]: failed to open the modules file
[cvs] file created by merge
Anchor(epiphany-browser)[https://launchpad.net/people/seb128 seb128]: https://launchpad.net/products/epiphany-browser/main BR :pserver:email@example.com:/cvs/gnome epiphany BR [Date(2006-10-16T14:54:17Z)]
- The cscvs log (with changesets) first mentions epiphany-toolbar at changeset MAIN.67, it refers to revision 1.2 of this file and records it as a 'M' (modification), which fails to apply since the file is not present in the imported tree at this point.
Relevant fragment of the cvs log:
$ cvs rlog epiphany/data\/ui/epiphany-toolbar.xml.in RCS file: /cvs/gnome/epiphany/data/ui/Attic/epiphany-toolbar.xml.in,v head: 1.17 branch: locks: strict access list: symbolic names: [...] eog-menu-api: 22.214.171.124 keyword substitution: kv total revisions: 19; selected revisions: 19 description: ---------------------------- [...] ---------------------------- revision 1.2 date: 2003/01/20 18:57:15; author: mpeseng; state: Exp; lines: +15 -0 2003-01-20 Marco Pesenti Gritti <firstname.lastname@example.org> * Merge eog-menu-api branch ---------------------------- revision 1.1 date: 2003/01/20 17:53:25; author: mpeseng; state: dead; branches: 1.1.2; file epiphany-toolbar.xml.in was initially added on branch eog-menu-api. ---------------------------- revision 126.96.36.199 date: 2003/01/20 17:53:25; author: mpeseng; state: Exp; lines: +15 -0 implement context menus ---------------------------- [...]
[svn] Cannot import whole repository
The svn import code fails at processing imports at the root of a svn repository. Some repository are set up that way, with the actual root containing the source code. That's broken, but people actually do this.
[cvs] None branch in findLastFileRevision
While creating changesets: assertion error, branchName is None in findLastFileRevision CVS/CacheGenerator.py:160
It looks like it means something is really busted with filler revisions and default branches.
File name not supported by bzr
on changeset MAIN.4167: BR CRITICAL: requested checkout of reporoot '/cvsroot/xrms', file 'xrms/include/adodb/pear/Attic/readme.Auth.txt', revision '188.8.131.52' 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->184.108.40.206 for include/adodb/pear/readme.Auth.txt, but there is no revision 220.127.116.11 for that file. The cvs rlog shows revision 1.1 (branches: 1.1.1) used in changeset MAIN.915, revision 18.104.22.168, not used by cscvs. The cvs log header for that file reads "head: 1.1" and "branch: 1.1.1".
(15:28:25) lifeless: I'd do a search in the file revision table for that file, all revisions, see what cscvs is thinking happened to it (15:29:45) ddaa: you suggest it might be a problem in the log parser and checking the catalog contents would help narrowing the cause of the problem? (15:33:11) lifeless: something is inventing the .2 (15:33:22) lifeless: if its in the catalog then the catalog generator can be checked (15:33:42) lifeless: if its not in the catalog then the application-of-changesets can be checked (15:33:45) lifeless: it will narrow it down (15:34:03) lifeless: As its a very small rlog I'd make a test case from it
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
Fix in progress
Failures for which a fix is currently being worked on.
[svn] 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.
[svn] Better REPLACE support
Imports that have failed and that need better support for replaced files.
[svn] Partial copy
Current cscvs in production does not correctly handle revisions that combine a copy (that is 'A' or 'R' action with copyfrom set) with a simultaneous delete ('D' or 'R' action) in a path below the copy.
A new changeset generation logic that fixes this issue has been implemented and is currently undergoing review. When the code review and fixage has been completed, those import will be re-run and are expected to succeed.
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.
- On changeset 10376