Joseph S. Myers <[EMAIL PROTECTED]> wrote: >> You can always see them with the [EMAIL PROTECTED] syntax >> >> ie >> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED] > > Which requires remembering an arbitrary revision number (i.e., making > life *harder* not *easier* for people looking for that branch) > rather than a more meaningful branch name.
And? The revision number can easily be found with an automated svn log | grep command, or can be written in svn.html, or wherever. Let's not remember that inspecting a dead branch is the *rare* case here. I consider the noise in "svn ls branches" way more important. > Abstractly, the history where a branch has been merged into mainline > is > > mainline -------------------------------------------- current mainline > \ / > \ / > branch------- > > (where the branch is ancestral to the current mainline, and logically > branch-of-today is a hard link to mainline-of-tofay), not > > mainline --------------------------------------------- current > mainline \ > \ > branch------dead > > and while version control doesn't effectively represent the first form > (multiple versions at the same time being ancestral to the same > current > version), I don't think tricks with revision numbers should be needed > to see the ancestry of mainline. Say you are looking into the history/annotation of a certain file, and you see that a certain line/function you are interested it was changed exactly with a commit which merged a branch. Then, the commit log will clearly mention the branch name. Moreover, the commit number is the exact revision number you need to start doing "svn log" into the branch. So, you'll always have what you need there, handy for use. I would find it *way* more annoying having to search for the branch in a complex /branches hierarchy (was it moved to /branches/closed? Or is there a /branches/Apple/closed? Or is there a /closed? Ah nice, it was /branches/codesourcery/jsm/closed). > In order to avoid referencing arbitrary revision numbers Here's the problem! In SVN, it is really common to reference arbitrary revision numbers, since the same number conveys multiple meanings (an exact reference of the tree, an exact reference to an atomic commit). Revision numbers *will* proliferate in GCC mailing lists in bug reports, commit reports, mailing lists, and whatnot. This is something which just happens with SVN repositories, and people get used to it (and mostly, find it very handy). You just can't assign a name to everything, and I don't see how "the commit that broke mainline two days ago" is less important that "the commit which closed an internal Apple development branch". If you're trying to fight the use of revision numbers, you're basically running against a thick wall. I have a feeling that this discussion is going to be unproductive because it is made just of our intuitions and expectations. There's no real-world concrete use case. Giovanni Bajo