A meta-issue for the work required to ditch CVS, once and for all. Blocks/Depends on relationships will be added for all subtasks.
My past messages to the various lists discuss the relevant issues. I still think a combined binutils+gdb git repository (without any of the other pieces from the src repository) is probably the best trade-off. http://sourceware.org/ml/gdb/2011-10/msg00134.html is one of my more recent messages on this subject (you'll find plenty more relevant information in that thread and in the other threads on the subject over the past several years on both binutils and GDB project list).
Thanks Joseph! Let's discuss this onthe list for maximum transparency and I'll collate the results from past and present discussions here as we go! :-)
It would be helpful to collect a list of concrete tasks to be done. I'm assuming, per the threads, that a shared gdb+binutils repository would be created. * make src-release ignore .git (trivial) see the CVS_NAMES variable * update the gdbadmin scripts * update the BFD daily date-updating commit * port log_accum_bugzillafied to git * likewise, set up git commit email * update DJ's script that auto-merges top-level changes from GCC * examine gdb and binutils documentation to see what needs to be updated. This means looking at the texinfo manuals, the web sites, and the gdb wiki. Is there anything I've missed? Once the conversion is in place we can add: * mark the various converted directories as read-only in CVS
> * make src-release ignore .git (trivial) > see the CVS_NAMES variable Testing reveals that we don't need this. > * update the gdbadmin scripts I've done this but have not tested them. > * port log_accum_bugzillafied to git I've done this. I've partially tested it (I tested the post-receive script modifications). See also bug #13746. > * likewise, set up git commit email This is really part of the previous task.
> * examine gdb and binutils documentation to see what needs to be > updated. This means looking at the texinfo manuals, the web sites, > and the gdb wiki. I've done this locally.
I forgot a to-do item: * Disable the current cvs->git importers Also there is the question of what to call the resulting repository. This affects at least the documentation. I'm using "src.git" for now, but it can be discussed.
Joseph pointed out that we want to stitch in the pre-sourceware CVS history, which is available: http://sourceware.org/ml/binutils/2012-10/msg00407.html There are a few candidates for merging this in: 1. Whatever mysterious process Ian refers to in that email; 2. reposurgeon 3. git stitch-repo 4. git grafts plus git filter-branch
Tom, I've been reading your updates to this, and enjoying seeing progress! :-) About the last comment, though: Anything that disrupts current Git users should probably be avoided. Get it into Git, sure, but why not just leave it on a branch called pre-sourceware or similar? This should have been done up front really. If it's being done now, everyone should be notified heavily before the existing history is smashed/re-hashed and anyone down stream is broken by it. I know a lot of people came forward and stated they work in Git, and commit in CVS, I personally know of people that do this. My 2c, likely best to avoid changing it at this point with widespread cloning/use already in action.
(In reply to Fred from comment #8) > About the last comment, though: Anything that disrupts current Git users > should probably be avoided. Get it into Git, sure, but why not just leave it > on a branch called pre-sourceware or similar? We're making a new gdb+binutils repository, for reasons outlined in the various threads -- so current users will already be inconvenienced. Note that the inconvenience is pretty small. An existing branch can be migrated quite easily via git am, just by finding the corresponding branch point. There are probably other ways as well. > This should have been done up > front really. The history wasn't publicly available when the mirror was created. > If it's being done now, everyone should be notified heavily > before the existing history is smashed/re-hashed and anyone down stream is > broken by it. We won't overwrite gdb.git or binutils.git. We'll have a new src.git and mirroring to the existing it repositories will be disabled. Current users will pay a small one-time transition cost.
OK, fair enough! As you were :-)
Can I suggest a commit log policy change when we switch to git? Something like: The commit log should generally consist of the subject line in your mailing list patch submission, followed by the url of the patch, the explanatory text you wrote in that email, and optionally, the ChangeLog entry for your patch. Do *not* include the actual patch in the log message! For example, here is one I wrote for a glibc patch. PowerPC SIGSTKSZ http://sourceware.org/ml/libc-alpha/2013-08/msg00093.html This copies the sparc version of sigstack.h, which gives powerpc #define MINSIGSTKSZ 4096 #define SIGSTKSZ 16384 Before the VSX changes, struct rt_sigframe size was 1920 plus 128 for __SIGNAL_FRAMESIZE giving ppc64 exactly the default MINSIGSTKSZ of 2048. After VSX, ucontext increased by 256 bytes. Oops, we're over MINSIGSTKSZ, so powerpc has been using the wrong value for quite a while. Add another ucontext for TM and rt_sigframe is now at 3872, giving actual MINSIGSTKSZ of 4000. The glibc testcase that I was looking at was tst-cancel21, which allocates 2*SIGSTKSZ (not because the test is trying to be conservative, but because the test actually has nested signal stack frames). We blew the allocation by 48 bytes when using current mainline gcc to compile glibc (le ppc64). The required stack depth in _dl_lookup_symbol_x from the top of the next signal frame was 10944 bytes. I guess you'd want to add 288 to that, implying an actual SIGSTKSZ of 11232. The subject should be on a line by itself and not exceed 75 characters. You should have chosen a subject that was a reasonable summary of your patch when writing your patch submission. This helps the relevant maintainer notice your patch, and helps people searching for a bug fix. We ask for this in the commit log too, because a number of tools display the first line of git commit logs. The url of your patch allows people to easily find discussion related to your patch. The explanatory text is there in the commit log to aid people working with the sources offline. The ChangeLog entry in the commit log is optional except when you did not include explanatory text in your patch submission, which might be reasonable if the ChangeLog entry is self-explanatory. There are of course exceptions to these rules. For example, a single line commit log saying "regenerate configure" is acceptable if that is all you are doing.
There should be an empty line after the subject line.
My CVS stitching process is not so mysterious, it's in the CVS repository :ext:sourceware.org:/cvs/sourceware/coolo-cvs on the gccmerge branch. The main command is in src/gccmerge.c. A few constants in that file would have to be changed for the binutils code. But if git has a stitching process, no reason not to use that.
(In reply to Alan Modra from comment #11) > Can I suggest a commit log policy change when we switch to git? In my proposal I ask that these things be considered separately. I'm in favor of many process changes, including this one, but I want to focus on just the conversion, which is pretty complicated by itself. FWIW many gdbers have already switched to git-style commits in the CVS repository.
(In reply to Ian Lance Taylor from comment #13) > My CVS stitching process is not so mysterious, it's in the CVS repository > :ext:sourceware.org:/cvs/sourceware/coolo-cvs on the gccmerge branch. The > main command is in src/gccmerge.c. A few constants in that file would have > to be changed for the binutils code. > > But if git has a stitching process, no reason not to use that. Thanks, Ian. The cvs approach may be easier in practice for this, though I still haven't fully researched the git approaches. I'd like to get a copy of the old CVS repository. Can you put it up for ftp somewhere?
A few more to-do items: * Git migrations and work-flow offered for remaining projects (like newlib and cgen). * (related:) Do not set in stone this git repo as "binutils+gdb" in any documentation changes and names assuming we agree that other projects may be added. * Add remaining "partial checkout" methods as mentioned in CVSROOT/modules to src-release, for related migrating projects (well, at least "sim"). Mention this as a (the only?) supported way to generate the project-specific tree. See <http://sourceware.org/ml/binutils/2013-08/msg00281.html> for reasons.
On Fri, 30 Aug 2013, hp at sourceware dot org wrote: > * Git migrations and work-flow offered for remaining projects > (like newlib and cgen). That should be in the form: document in detail how the migration worked, so that if the newlib community chooses to move to git, it has the benefit of documentation of the process when replicating it to move to its own git repository. > * (related:) Do not set in stone this git repo as "binutils+gdb" > in any documentation changes and names assuming we agree that other projects > may be added. Rather, I say the repository should be exactly 6(b) from <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html> (subject to confirming the exact set of directories with only Attic contents in CVS whose history gets converted). (c), (d), (e), (f), (g) and each of the three parts of (h) should, if someone in their respective communities wishes to convert them away from CVS, be converted independently to separate repositories (based on shared toplevel code only when it's actually used); (a) may be convenient to avoid shared files diverging, but is not required. (I do not definitively assert whether (c) newlib and (d) winsup should be separate or a single repository; that's for the relevant communities to work out. I am confident that all the other divisions make sense.)
(In reply to joseph@codesourcery.com from comment #17) > On Fri, 30 Aug 2013, hp at sourceware dot org wrote: > > > * Git migrations and work-flow offered for remaining projects > > (like newlib and cgen). Sorry, there was an ambiguity here. By "work-flow" I meant "git-migration-unrelated usual work-flow, of checking out and building and committing changes to files affected by the migration changes", not specifically "work-flow of git migration" - though that makes sense too on its own. > That should be in the form: document in detail how the migration worked, > so that if the newlib community chooses to move to git, it has the benefit > of documentation of the process when replicating it to move to its own git > repository. Not sure if your reply was affected by the ambiguity of my suggestion, but anyway your suggestion makes sense. > > * (related:) Do not set in stone this git repo as "binutils+gdb" > > in any documentation changes and names assuming we agree that other projects > > may be added. > > Rather, I say the repository should be exactly 6(b) from > <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html> If the src CVS is to be able to continue on its own then there's one or two missing TODO items last: * Undo the read-only marking of the subset of converted directories that are shared with non-migrated projects. (For example: config/) and * Alert all non-migrated projects affected by converted directories.
(In reply to Hans-Peter Nilsson from comment #18) > Sorry, there was an ambiguity here. By "work-flow" I meant > "git-migration-unrelated usual work-flow, of checking out and building and > committing changes to files affected by the migration changes", not > specifically "work-flow of git migration" - though that makes sense too on > its own. I don't follow this. Could you give an example?
(In reply to Tom Tromey from comment #19) > (In reply to Hans-Peter Nilsson from comment #18) > > > Sorry, there was an ambiguity here. By "work-flow" I meant > > "git-migration-unrelated usual work-flow, of checking out and building and > > committing changes to files affected by the migration changes", not > > specifically "work-flow of git migration" - though that makes sense too on > > its own. > > I don't follow this. > Could you give an example? The work-flow changes unrelated to the act of moving to git but affected by the combined (and separated) repository. The simplest example would be the extra options needed to configure for configuring *only* binutils (*without* gdb and *without* sim) in the "<path>/configure && make && make check" work-flow (alternatively the release-tarball method, but that's more involved than I expected). For separated projects, e.g. cgen, you would also need a separate tree when testing your cgen changes or changes to files in src/cpu/* instead of just checking out cgen along with your sim or binutils tree. So, the bullet-point being to test these changes in development work-flow works (that the binutils configure option above works and that the cgen separation works - patch needed there), post them to the respective lists. For newlib, I guess there wouldn't be much change in work-flow (needs gcc too, so also has overcome any tree-separation anxiety with gdb and binutils). And now that you've read this far, how about that src-release patch for sim? I'll add a pointer in my next comment.
(In reply to Hans-Peter Nilsson from comment #16) > * Add remaining "partial checkout" methods as mentioned in > CVSROOT/modules to src-release, for related migrating projects (well, at > least "sim"). There seemed to be only "sim". Patch is awaiting approval at <http://sourceware.org/ml/gdb-patches/2013-09/msg00257.html>.
Doing it.
Whew. I hope.