Re: CVS commit: src/sys

2020-04-18 Thread Robert Elz
Date:Sat, 18 Apr 2020 10:29:33 +
From:m...@netbsd.org
Message-ID:  <20200418102933.ga24...@homeworld.netbsd.org>

  | I feel like it's difficult to decide which is objectively better.

It all depends upon usage patterns, and objectives.

  | CVS encourages you to keep your local changes uncommitted, so they do
  | not show up in a change to RCSID at all.

Yes, that's a problem.   I'd actually prefer it if the compiler were to
add a note (of some kind, as long as it appears in the actual binary)
with the filename, mod date, and checksum, of every file it includes in
each compilation unit.   If there's also a VCS ID of some kind that can be
associated, even better.

The point was that a single identifier for the whole build simply
isn't detailed enough to be useful in many cases - it certainly wasn't
that CVS is better than something else.

  | But as a person with access to the repository, you are in a better
  | position in this case, because the DVCS will make it easy to go back to
  | the state of the tree given a hash, even after you add changes later.

I have had an off-list discussion with wiz about some of this - part of the
point is that often the person who wants to know whether a particular
version of a file was included has no reporitory access at all.   The
repository might not even still exist.   One of the questions we would
like to be able to answer is whether two different distributions were
built with the same version of some particular file - if that file is
later discovered to have been harbouring a bug.  And it would be nice to
be able to do that in isolation (no references to anything other than the
two (binary) distributions).

  | I imagine it isn't impossible to find 'closest parent which is also in
  | the remote' and embed it as well, mitigating the "outsider can't tell
  | how far you are" concern, if someone wants to pursue that.

To my mind, within reasonable cost bounds (space and effort) the more info
that is included the better.   It is always easy to simply ignore if not
needed, or redundant, but often impossible to reconstruct if missing.

kre



Re: CVS commit: src/sys

2020-04-18 Thread maya
On Fri, Apr 17, 2020 at 11:39:01PM +0700, Robert Elz wrote:
> Date:Fri, 17 Apr 2020 07:52:53 -0700
> From:Jason Thorpe 
> Message-ID:  <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com>
> 
>   | The New Hotness (which isn't particularly new, at this point)
>   | is to create branches and merge what you want into that branch.
> 
> What I don't understand, is how this single commit-id works in practice
> (not how it is generated, I mean how it is used).   Say you've got some
> local changes you're testing, maybe some ARM device driver (or related
> stuff), and I have local changes as well (maybe some new sh code - I
> actually have a lot of that, though most of it is no longer "new" and
> quite possibly none of it will appear in public) - so we're both working
> from different states of the overall tree.   Hence different ID's right?
> 
> Now imagine that while testing, some schedueller bug causes a panic,
> or the ATF tests detect some (unrelated to both of us) failure that
> shouldn't be happening (perhaps rump was neglected in someone's
> changes from elsewhere, yet again).
> 
> If we both, along with someone running a pristine tree, all see this
> failure, perhaps manifesting in slightly different ways, how do we
> all determine that we're running the same versions of all of the
> relevant files, and hence are probably all seeing the same bug?
> 
> Currently, with each file having its own version identfifier, it
> is easy, but if everything is to share one single "it is this version"
> ID, how can we know that we are all actually running the same version
> of whatever code broke and is affecting all of us?
> 

I feel like it's difficult to decide which is objectively better.
CVS encourages you to keep your local changes uncommitted, so they do
not show up in a change to RCSID at all.

Once you do local commits, it is hard as an outsider to know how far you
are from a remote tree.

But as a person with access to the repository, you are in a better
position in this case, because the DVCS will make it easy to go back to
the state of the tree given a hash, even after you add changes later.

I imagine it isn't impossible to find 'closest parent which is also in
the remote' and embed it as well, mitigating the "outsider can't tell
how far you are" concern, if someone wants to pursue that.