[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: odd cases

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-09-05 22:05:39 CEST

Yep, completely agree with the end result (now that I'm not misreading
Jim's example).

I think we have "consensus", as they like to phrase it in co-op land. :-)


Greg Stein <gstein@lyra.org> writes:
> On Tue, Sep 05, 2000 at 02:38:57PM -0500, Jim Blandy wrote:
> >
> > Suppose a user has a working directory containing a file, A, based on
> > version 10 (which I'll write `A:10').
> >
> > Assume that commits happen only when I explicitly say so; otherwise,
> > changes are just local to the working copy. Assume that all copies,
> > renames, etc. are done via the appropriate Subversion commands.
> "appropriate Subversion commands" is an important point here. It means that
> we are tracking what is occurring within the directory, and tracking the
> ancestry of the files.
> > The user copies A to B, yielding a new file B, based on A:10.
> >
> > The user updates the entire directory, and A is now based on version
> > 11; B is noted as an added, but not yet committed, file.
> >
> > The user deletes A.
> >
> > The user renames B to A. Now the working copy's A is based on A:10.
> The net effect here is that A is a NEW FILE whose ancestor is A:10. They
> happen to have the same name, but that does not alter the fact that it is
> a new file.
> An "update" will do nothing (except possibly remark on the added/uncommitted
> file named "A").
> A "commit" will check A:10 in as A:12. A change set (a version) in the
> server cannot record both a delete and an add for the same name (as far as I
> understand the "current" spec). Instead, it records an updated file with a
> specific predecessor. In this particular case, A:12 is created with A:10 as
> its predeccesor. A:11 has no successors, so it was presumably deleted.
> [ hmm. actually, we don't record predeccessors, do we? don't we just record
> "<this> file is in <this> version" ? only by comparing versions do we see
> the deltas between files? ]
> > Now, suppose the user does an update. No further changes have been
> > committed by anyone to the repository. Should A be brought up to
> > version 11? I think it shouldn't --- A's current text is something
> > the user explicitly chose. Their working copy is completely
> > up-to-date. I think Subversion should simply note that A is "locally
> > modified", and leave its contents alone. Do you agree?
> Agree.
> > Now, suppose the user does a commit. Should Subversion complain that
> > A is not up to date? Or should it simply check in the current
> > contents of the file --- effectively reverting the change made to A in
> > version 11? I think it should do the latter. This is the same
> > question as above, I think: "Is this file up-to-date?"
> Effectively, it will revert it. However, the predecessor/successor
> relationship is not "as you would expect". A revert would show A:11 as the
> predecessor and the net effect would be to reverse the A:10 -> A:11 change.
> In this scenario, the reality looks like:
> A:9 -> A:10 -> A:11 A:12
> \ /
> ----------
> Question is: can the SVN repository record this kind of relationship?
> > Now, when the user does a commit, what callbacks to the
> > svn_delta_walk_t structure need to happen? A single call to
> > replace_file doesn't work; the filesystem can't tell the difference
> > between that and attempting to commit an out-of-date version of A. I
> > think it needs to do a `delete', and then an `add_file'. I'm not so
> > sure about that. What do you think?
> You can do it either way:
> a) replace_file with an predecessor of A:10
> b) delete, followed by add_file with a predeccessor of A:10
> Both cases should resolve to the same thing.
> I'm okay with a declaration that only one form is "legal." I'd prefer option
> (a) if we make such a declaration. In other cases, we are going to want to
> have the ability to specify a set of predecessors (e.g. merges).
> Cheers,
> -g
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:07 2006

This is an archived mail posted to the Subversion Dev mailing list.