> 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.
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 don't yet understand the problem.
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.
> Are all of these user operations (commits,
> updates) done from within Subclipse?
Yes.
Originally, we were not running svn up against the folder selected, but
specifically for the files that svn st -u said were out of date. There
were two problems with this approach:
1) Performance, I already mentioned this in a reply to ghudson.
2) I forgot the bigger problem when I replied to ghudson, and that is that
when we were using this technique, folders were only ever updated if they
had a prop change. So when this was the method we got tons of questions
from people that did not understand the out of date messages they would get
when trying to add a prop to a folder or rename a folder.
To fix these two problems, we moved to the current logic which is what I
described above. If you select a "folder" in the tree, we update the
folder recursively. This solves both of the above problems, but turned out
to add this new problem.
The "fix" I made today was if the user selects a folder we always update to
HEAD. If they select just file(s) then we update to N where N is the
highest revision. And of course we only update the files.
The drawback to this fix is that there could easily be additional commits
that have been made to the repository since svn st -u was run, so the
update would pull down updates that the user was not presented with.
Ideally, there would be an option to the update API we use in JavaHL that
would say "update to revision N" but when a file whose revision is greater
than N is encountered, do not update that file.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 04:30:44 2006