commit philosophy

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

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?

Remember, I committed the whole foo/bar/ directory.  Does that mean
that when I'm done committing, foo/bar/ in the head revision should
look *exactly* like my working copy's foo/bar/, even if that means
effectively "retrograding" the node-rev-ids in revision 11?

(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?)

Re: commit philosophy

[Karl Fogel <kf...@collab.net>]

Seems I'm posting just to agree a lot, lately, but...

+1 w/ Greg and Tripp below (and, I suspect, with Ben as well, as he
was probably just playing devil's advocate).

Mixed revision working copies do not imply that the user wants every
commit to make the repository reflect that same mixture of
revisions. :-) 

Commits should transmit local _changes_, not local "arrangements"
(sorry, that's kind of a vague principle, but you know what I mean).

-K


Greg Stein <gs...@lyra.org> writes:
> On Thu, Mar 29, 2001 at 07:39:12AM -0600, 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?
> 
> Absolutely not.
> 
> > Or should it do *nothing* but
> > create a new revision of baz.c?
> 
> Yes.
> 
> I'm with Tripp on this one. This is the only viable and sensible thing to
> do. We don't want the client pulling old revs up to the latest tree.
> 
> CHeers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/

Re: commit philosophy

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Greg Stein <gs...@lyra.org> writes:
 
> > Here's the issue: should my commit cause revision 5 of foo/bar/bop/ to
> > be merged into the head revision?
> 
> Absolutely not.
> 
> > Or should it do *nothing* but
> > create a new revision of baz.c?
> 
> Yes.
> 
> I'm with Tripp on this one. This is the only viable and sensible thing to
> do. We don't want the client pulling old revs up to the latest tree.


Okay, this issue is moot.  You two, plus Karl and Jim, have persuaded
me that I must have been smoking something for breakfast. :)

Re: commit philosophy

[Greg Stein <gs...@lyra.org>]

On Thu, Mar 29, 2001 at 07:39:12AM -0600, 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?

Absolutely not.

> Or should it do *nothing* but
> create a new revision of baz.c?

Yes.

I'm with Tripp on this one. This is the only viable and sensible thing to
do. We don't want the client pulling old revs up to the latest tree.

CHeers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: commit philosophy

[Tripp Lilley <tl...@perspex.com>]

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>