Mark Phippard wrote:
>>I don't know Eclipse or Subclipse. Please could you explain in more detail the
>>sequence of Subversion operations that is involved.
>
> svn st -u equivalent is run to build up a list of local and remote changes
> which are presented in a tree-like structure.
OK, and I gather this is done in response to the user requesting "Let's
synchronise my WC with the repository, interactively letting me choose which of
my changes to commit and which to revert, and helping me to merge in all the
changes from the repository."
> User has options to run compares, update, commit, revert etc.
>
>
>>When you say "We have used
>>-r N" do you mean Subclipse chooses a particular revision number (which one?)
>
> User selects some files, or perhaps a common parent folder and chooses
> update. We run:
>
> svn up -r N
>
> Where N = highest revision number of selected items
I take it you mean the highest revision number that any of these items have
reached in the repository. In its effect on the selected files, this is
equivalent to choosing N=HEAD, because by definition no changes have occurred
to these items between then and HEAD.
But no, from your next paragraph, you can't mean that, because then N would be
high enough to include any recent commits to those files. So the highest of
what revision numbers is chosen?
> If a user does a commit after populating the view we have not done anything
> to refresh the view, because svn st -u is fairly expensive. The problem is
> that if they select say the root folder and run update, then the value of N
> is always less than the value they just committed. So the changes to any
> files they committed are essentially backed out of the working copy.
Right. Yes. Naturally. If you want to keep the local changes, then you
either have to keep them as local changes, or commit them, but if you commit
them, then they are going to exist at a revision greater than N so you will
have to synchronize to a revision greater than N.
It seems to me this is a conceptual problem. You need to think about what is
the intended meaning of selecting a sub-tree for a long-running "synchronize"
procedure, in terms of what the user is expecting to get at the end of it. It
is simply not possible to say that we will synchronize a tree to revision N
while allowing the user to perform commits that will take one of the files to
revision N+2 (say), because the same file may have been changed by someone else
in revision N+1.
It seems to me that this procedure is designed to work with
individually-versioned files, and probably needs to be redesigned a bit to work
with a whole-tree versioning system. In thinking about and describing a
whole-tree version of the human-level procedure and result that you are trying
to achieve, you will probably find that it maps naturally onto the Subversion
operations that are available.
I certainly don't mean this as a brush-off type of response. If you really
need to use Subversion in a manner as close as possible to the file-at-a-time
model, I dare say you'll find a way that works tolerably well in general, but I
doubt it will be very satisfactory. Regardless of the operations that
Subversion allows, what result can you desire in the N+2/N+1 case I mentioned
above?
(Thanks for the further explanation and history.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 18:53:12 2006