Julian Foad <julianfoad@btopenworld.com> wrote on 02/28/2006 11:18:37 AM:
> 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."
Correct, the option is called "Synchronize with Repository". There is a
screenshot on this page:
http://subclipse.tigris.org/screenshots.html
> > 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.
N does not have to equal HEAD if there are files involved, because the svn
status API we use gives us the last changed revision of the files. But
for the sake of discussion, let's just say N=HEAD because that is not
relevant to the problem. The issue is that N=HEAD (at time option was
taken). Once you do some commits, N < 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?
The previous answer probably clarifies, but N is chosen based on the
highest last changed revision of the items you selected.
> 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?
You are probably right, but we have no choice but do our best to support
the feature as Eclipse users all but mandate it. The change I made to use
HEAD when a folder is the item being updated should suffice in the near
term. If we are pressed on the issue, I will probably just need to add
some code to check if HEAD has been advanced since the start of the
operation and update/message accordingly.
Thanks
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 19:19:21 2006