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 <thor...@me.com>
>     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.

Reply via email to