Re: commit philosophy

On 29 Mar 2001, Ben Collins-Sussman wrote:

> Philosophical question about commits.
>
> * Suppose I have a working copy at revision 3, and the head revision
> on the repository is 10.
>
> * Suppose a file "foo/bar/baz.c" has a local change. So lazily, I
> type 'svn ci foo/bar'.
>
> * However, suppose that baz.c has a sibling subdir, "foo/bar/bop/", at
> revision 5.
>
> Here's the issue: should my commit cause revision 5 of foo/bar/bop/ to
> be merged into the head revision? Or should it do *nothing* but
> create a new revision of baz.c?

Unfortunately, I haven't yet read the design docs, so I'm only as familiar
with svn's underlying view of commits / changes / etc. as one can be from
skimming the list traffic :( Since ignorance has never stopped me, before,
I offer this :)

In the Perforce view of the world, this is a "non issue". The server is
aware of your client's existence, and aware of what files, at what
revisions, are synced to your client. When you submit a change, Perforce
only cares which files are different than the versions synced to your
client. So when it looks in foo/bar/bop/..., it's comparing those contents
(which are at rev 5, by your example) to the depot contents at rev 5, even
though the depot is at rev 10.

To me, that's sane, because YOU HAVEN'T MADE ANY CHANGES to that
directory. The fact that you happen to have a stale copy doesn't mean that
you -want- that stale copy to propagate to the head of the mainline. In
fact, Perforce requires a specific act of will to bring an old revision to
the fore:

        [1] p4 sync @5 foo/bar/bop/...
        [2] p4 edit foo/bar/bop/...
        [3] p4 sync
        [4] p4 resolve -ay
        [5] p4 submit

Step 4, the resolve, is necessary because the contents of foo/bar/bop/...
have changes which conflict with the head revision (Perforce warns you, in
effect, that you have a stale copy)

> (I ask this question, because I just realized that we're *not* doing
> that right now. Our commit-driver, crawl_local_mods, won't call
> replace_dir(5, foo/bar/bop/) unless it specifically finds an add,
> delete, or local file mod somewhere inside foo/bar/bop/. Is this
> wrong?)

IMHO, this is absolutely -right-. Remember... as a user, you didn't
actively -change- anything. You just happened to let your copy get stale.
That shouldn't frag the whole tree :)

PS: By way of belated introduction, I'm a Perforce User ;) In fact,
Perforce holds the distinction of being one of the only two pieces of
closed-source software that I will use or recommend in a production
environment, at least until there are open source alternatives.

-- 
   Joy-Loving * Tripp Lilley  *  http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
  "Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>