On Mar 14, 9:38 pm, Ryan Schmidt <subversion-20...@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.
