On Wed, Oct 09, 2002 at 12:27:39PM -0400, Greg Hudson wrote:
> Why does your build system look at the rev-id of files?
Because it's "smart" the way ClearCase clearmake is, or ODIN,
or Cons. because it knows that sometimes the date might look
okay, but if its a different rev than what I had before, it
still needs to be rebuilt. Just because the rev-id of the file
being referenced by my workspace has changed doesn't necessarily
mean it has become more recent. I might now be referring to a
revision that was created less recently, and unless my build
system knows whether or not the underlying VC tool is using
any kind of "virtual file system" type stuff, it can't assume
that the date-change will always be forward. (I once worked
with a VC tool that used a symlink-farm, similar to BCS, to
"cache" shared immutable versions across NFS. So sometimes
the date I wanted it to use was the time of the symlink,
not of the file it linked to)
If I do an "update" refer to a new revision of a file I never
checked-out, I don't want to have to rebuild just because the
rev-id changed, when the contents didn't actually change at all.
Why should the VC system insist that the file-version has
changed when its contents did not? I can see it insisting on
knowing there was a change to the configuration that the file
participates in, but just because I changed one thing in the
configuration doesn't mean I changed everything. I don't any
tools that have to operate in the VC environment. I would
still want the files to have their own version "identity"
as well as also being associated with the identity of the
contextual configuration in which they were changed.
Sometimes I call it the "wave versus particle" view of a
change. I want my VC tool to allow me to view it either way
(maybe not both at the same time, but when I want to see the
"particle" view and know the individual rev-id of a file in
isolation from the the rest of the configuration, I don't want
it to get confused with the "wave" of context in which it came
along for the ride, but unchanged in this particular case).
> > * if I "commit" my changes, and if some of the files I changed did
> > have parellel/concurrent activity, but some didn't, does the archive
> > format record a new branch for ALL the files in my change-set, or just
> > the changed-files?
>
> This question is also difficult to understand. Strictly speaking, you
> can't commit a file which has had parallel/concurrent activity. You
> have to merge in the changes. (If you mean that a copy of the file had
> parallel/concurrent activity, then that makes very little difference to
> the archive format.) Regardless, we never record new information for
> files or directories which have not changed during a commit.
I think I'm defining things differently than you expect. I'll
clarify: Lets say I checkout a file from a certain revision. I
make changes. By the time I'm ready to commit my changes,
no one else has made any changes to the same file from the
same branch as the revision I checked out from. I'm the only
one that has made any such changes, therefore, no parallel
activity has taken place. When my revision of that file is
merged back to the codeline from whence I came, it will have
exactly the same contents as the version I checked-in during
my commit because there were no other contributors.
So for that file (and others like it) the contents on my
branch will be the same as the contents on the codeline after
my changes merged to the codeline. But they will be different
rev-ids.
--
Brad Appleton <brad_at_bradapp.net> http://www.bradapp.net/
"Education is the ability to listen to almost anything
without losing your temper or your self-confidence."
-- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 19:08:50 2002