From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16728 invoked by alias); 31 Jan 2019 19:50:24 -0000 Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org Received: (qmail 16590 invoked by uid 89); 31 Jan 2019 19:50:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*cgen, H*Ad:U*cgen, laying, june X-HELO: mail-wm1-f47.google.com Received: from mail-wm1-f47.google.com (HELO mail-wm1-f47.google.com) (209.85.128.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 Jan 2019 19:50:22 +0000 Received: by mail-wm1-f47.google.com with SMTP id a62so3765052wmh.4 for ; Thu, 31 Jan 2019 11:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=h8+elQKfrTyT557OXpHWpwqIggjuxgJHCkCV9ZSPsLA=; b=ZLheroVAlWsQOizWiMavsRapZs/JSmXKPnar8j1Yfm8HTAkKBeYlIO9dQsRmVMRzvC 6+KQMwRCwNwsA9FesjppY0rEaQ7o7d4zScO6Uy96ZMrW6aXrbL5zO3kG2235d6Yvw52P XMasoprvQd6u4lT8Bz3nokjtCJPQ9kynKylaKlBDnYizyoAC+vmpOb6TzOg5cvet9EWl LuNbOWEMbP0ZRcudErqsYjgqqJTDcgleK0XWyPmFgQsfeHdvuYtY59vYWlw+/w2wWUoh buD+nstXLugTy/Szr+W9BGYZCu3H2YI8e6flyxS+vl8COZ1l8PLG/ioBGcLkIhqXo5Jh D5EQ== Return-Path: Received: from localhost (host86-164-85-126.range86-164.btcentralplus.com. [86.164.85.126]) by smtp.gmail.com with ESMTPSA id a132sm329232wmh.5.2019.01.31.11.50.18 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 Jan 2019 11:50:18 -0800 (PST) Date: Thu, 31 Jan 2019 19:50:00 -0000 From: Andrew Burgess To: cgen@sourceware.org Subject: Converting CGEN from CVS to git Message-ID: <20190131195017.GB17699@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Fortune: Only a fool has no doubts. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00000.txt.bz2 I would like to discuss the idea of converting CGEN from CVS to git. Motivation ========== I have been working with CGEN off and on for the last 8 years, and though I haven't posted any fixes upstream in that time, I do have a set of fixes locally that I would like to try an upstream over the next year. Obviously, moving from CVS to git isn't a requirement for working on this project, but hopefully we can all agree that moving out of CVS makes development easier, and git seems like the obvious choice. Summary ======= I've done some initial work on a git conversion. My converted repository can be found here: git@github.com:T-J-Teru/cgen.git And the scripts I use to perform the conversion, along with a detailed README that lists all of the validation I have done on the conversion (summary below) can be found here: git@github.com:T-J-Teru/cgen-2-git.git History of the CGEN Repository ============================== I think most people reading this will already know this history. But, by laying out my understanding you'll be able to correct me if it turns out what I think I know is actually wrong. In the past many tools hosted on sourceware.org existed in a single large CVS repository and made use of CVS's module system to allow a subset of subdirectories to be checked out using a single name. So, GDB existed in this repository, and a request to checkout 'gdb' would give you the top-level directory, the gdb subdirectory, and also the bfd subdirectory, the libiberty subdirectory, the opcodes subdirectory, and so on. The binutils project was also in this CVS repository, checking out 'binutils' would give you the same top-level directory as for 'gdb', but then the gas, ld, bfd, libiberty, opcodes, etc subdirectories. Notice that some subdirectories are common to both projects, while others are specific to a single project. The CGEN project was also in this CVS repository, its main components are in the 'cgen' subdirectory, but a number of other subdirectories are also included in a 'cgen' checkout. If a user had checked out the binutils project, and then wanted to regenerate the CGEN components, they could simply ask CVS to checkout the 'cgen' project in the same location, and any additional subdirectories required for the 'cgen' project would be fetched from the server. Then binutils and gdb moved from CVS to git. We now have the binutils and gdb project in a single shared git repository, leaving CGEN behind in CVS. So, until a few months ago if a user wanted to rebuild the CGEN components the only way was to checkout binutils-gdb from git, then checkout CGEN from cvs to a separate location and copy the cgen subdirectory from the cvs checkout into the git repository. After this the user can continue to use CGEN. A few months ago I improved on this by changing binutils-gdb so that it could make use of CGEN in a separate location, avoiding the need to copy the cgen subdirectory around. This was done in this patch series: https://sourceware.org/ml/gdb-patches/2018-11/msg00061.html Now the user only need checkout binutils-gdb to one location, checkout CGEN to a separate location, configure binutils-gdb to know where CGEN is after which they can regenerate the CGEN parts of binutils-gdb as needed. It is now possible to maintain a clean separation between binutils-gdb and CGEN during development. Conversion Design ================= The observation that in order to regenerate the CGEN components, the only part of the cgen CVS module that needed to be copied into the binutils-gdb was the cgen/ subdirectory was the reasoning behind one big choice I made, that is: Only the cgen subdirectory of the current cgen CVS module would be included in the new git repository. Everything else is unneeded clutter, and should be discarded. As CGEN is not very active right now I made the choice to discard almost all branches when converting. My assumption is that the old CVS module will remain available in read only mode, so if an historical branch is needed then it can always be recovered later. The only branches I kept are the main development branch (now master) and the 1.1 release branch (called cgen-1_1-branch). Conversion Status ================= After the conversion there are only two branches in the CGEN git repository, 'cgen-1_1-branch' and 'master'. The only tags are 'cgen-1-0', 'cgen-1-1', and a set of tags matching the pattern 'cgen-snapshot-*'. The 'cgen-1-1' tag was added during the conversion, and matches what was released as CGEN version 1.1. This is simply the tip of the cgen-1_1-branch. Other than cgen-1-1 (which doesn't exist in CVS) every branch and tag has been manually checked out in CVS and git and compared, and in all cases the content matched. The release tags cgen-1-0 and cgen-1-1 have been compared to the contents of the release tar files, no differences were found. I have then used the latest version from CVS, and the HEAD of master from git to regenerate all of the CGEN created files in the binutils-gdb/opcodes subdirectory, and in the binutils-gdb/sim subdirectory for targets that use CGEN. In all cases the files regenerated from CVS and git were identical. Additionally, I checked out the sid project and confirmed, again using the latest from CVS and HEAD of master from git, that the regenerated files matched. I would be interested to hear any additional ideas for testing that I should perform. Other Infrastructure ==================== Until June 2018, a new snapshot tag was generated every month. After June this stopped. I don't have visibility of the script performing this tagging, but this script would need to be updated to work with a git repository (if we wanted the tagging back again). Is there any other infrastructure that would need to be updated around CGEN? I am happy to help with (or do) script rewrites if that is required. Next Steps ========== What I think needs to happen next: + Interested people review the conversion and give feedback. + I update based on feedback and repeat until we're all happy. + I and/or others update any support scripts that are identified. + Create a git repository on sourceware.org and import conversion. + Switch cgen part of old CVS repository to read only mode. The feedback and update depends on people reviewing and giving feedback. I don't have permissions to create a git repository on sourceware, or change the admin settings on CVS, nor am I sure who to approach. When we get that far any advice would be great. Finally, is there anything else I can or should do to help make this happen? Thanks, Andrew