This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tag reorg


Joseph S. Myers <joseph@codesourcery.com> wrote:

>> You can always see them with the url@rev syntax
>>
>> ie
>> svn ls svn://gcc.gnu.org/svn/gcc/branches@105944
>
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]