On Mar 14, 9:38 pm, Ryan Schmidt <subversion-20..._at_ryandesign.com>
wrote:
> On Mar 14, 2011, at 13:57, rupert.thurner wrote:
>
> > the eclipse cvs client allows to reject a change by simply clicking
> > "mark the local file as merged", and commit it.
>
> > There are multiple enhancement requests filed against sublicpse which
> > get rejected because "svn does not offer such a feature via API" and
> > "we (subclipse) do not tinker with your files, except via svn API",
> > see e.g.http://subclipse.tigris.org/issues/show_bug.cgi?id=761.
>
> > Alone from the number of requirements its seems pretty clear that
> > users do want this feature. But I am wondering what the correct place
> > to implement would be? Or to put it in other words, if one would
> > implement the feature into the svn command line client, where would
> > this feature go? above or below the API?
>
> Perhaps you could begin by explaining what the feature is? For the benefit of those of us who are not familiar with Eclipse CVS or its "mark the local file as merged" feature.
a gui tool like eclipse cvs, and also tortoise svn i think, allow a
visual compare of an incoming change. if the change is not good, one
can "mark" the local copy as the new version, and commit it over the
version in the repository.
subclipse allows this only if the local file is modified as well.
if the local file is not modified, it is epected that you _have to_
update the remote version, roll back somehow to the previous state,
and commit it. i.e. no support whatsoever by the tool. mark phippard
argues that this is the right way to do as subversion does not offer
an api call to mark the local version as changed, if i understand his
comment correctly in the subclipse issue 761.
rupert.
Received on 2011-03-14 21:52:14 CET