libqof change - not complete yet.

[Josh Sled]

On Mon, 2005-11-07 at 17:29 +0000, Neil Williams wrote:
> On Monday 07 November 2005 5:07 pm, Derek Atkins wrote:
> > Who asked for that?  I've asked for emailed-in patches to be small..
> > But who ever said that SVN commits should be small?  SVN commits
> > should be functionally-complete objects.
> 
> OK, understood. (The request was probably from the cvs time - something about 
> keeping commits logically coherent.) Looks like I took that one stage too 
> far. Sorry.

No, not far enough.  Logically coherent in this context means "one `svn
commit` for the entire related set of changes."


> From the svn book, it looks like it's actually update I need to call:
> 
> $ svn update --revision PREV foo.c
> # rewinds the last change on foo.c.
> # (foo.c's working revision is decreased.)
> 
> Is it:
> svn update --revision r11887
> ? More confusion.

I'm pretty sure you want:

 $ svn merge -r HEAD:11877

An `svn update -r [...]` makes your WC into the old copy, but I'd
imagine you then can not commit it as it's out of date.

The `svn merge -r M:N` merges the changes between HEAD and r11877, in
reverse order, to the WC ... in effect merging the changes back out.

You might want to do that against a new/clean HEAD WC to isolate the
merge from any other local cahnges.

[Also NOTE That it's 11877 we want to go back to, not 11887.]

You may want to read
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.2 a bit
for more context/info.


> svn revert appears to only work on files not revisions:
> $ svn help revert

Yes, and it only reverts to the single version you had before local
modifications; `svn revert` has a very limited scope.


On Mon, 2005-11-07 at 17:38 +0000, Neil Williams wrote: 
> > I don't know why you didn't 
> > get your WC into the tested state you wanted before committing all the
> > changes at once.
> 
> That's what I tried to do - the problem (as I saw it) with svn move is that 
> you have to have know that the moved file will still work in it's new 
> location and there were quite a few makefile changes that I had to test with 
> the files in place. Doesn't svn move commit to the repository immediately? 
> (If not, that is the source of my confusion.)

No.  `svn mv WC1 WC2` (strictly in the working copy) just schedules the
changes locally.  See `svn help move`. You can then make modifications
to the files as needed to get them to work in their new locations.

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`