On 7/30/06, Alex Turner <armtuk@gmail.com> wrote:
> Well - I first did:
>
> svn mv a/ b/
>
> then a bunch of other changes in b/
>
> then tried
>
> svn commit
>
> but when I tried the commit it told me the working copy was out of date, so
> I did an update. the update didn't seem to do anything much, but when I
> tried to commit again it failed. I have had problems with svn mv all day
> long to be honest, and I'm sorry I was a little petulent, today has been one
> long nightmare. (I'm working at 9:17pm on Sunday, what more do I need to
> say ;).
Well, unfortunately, any reproduction recipie that includes the words
"and then a bunch of other changes" isn't very useful when you're
trying to reproduce the problem. Additionally, it's likely that a bug
that produces this particular kind of error is going to depend on
things that were done to the file/directory in question in previous
revisions, not just the one you're making now. So ideally what I'd
like is a set of commands that can reproduce the error from scratch.
Failing that, the verbose history of the file that the error occurs
on, plus the actual commands that were run prior to the commit would
be a good starting point.
> svn mv seems to get angry when you try and do anything else along with it.
> I have been refactoring code and updating interfaces, so I've been moving
> stuff around and making superficial changes to classes in my source.
>
> To me it seems a little wierd that it told me that my working copy was out
> of date as I only have one working copy in which changes are being made
> currently, so I don't know how it could have been out of date.
The working copy out of date bit is because of mixed revision working
copies. See the FAQ for more details, suffice it to say that it's
normal, and almost certainly unrelated to the bug.
> I don't know how much help that is.
Well, not a whole lot, unfortunately. Other useful information in
addition to what I've already asked for would be the versions of svn
run on both the client and server, the type of filesystem used on the
server (fsfs or bdb), and the repository access layer used (file://,
svn://, http://, etc).
> (more comments further down...)
>
>
> On 7/30/06, Garrett Rooney < rooneg@electricjellyfish.net> wrote:
> > On 7/30/06, Alex Turner < armtuk@gmail.com> wrote:
> > > You know, for an atomic SCM, subversion sure as hell seems to leave my
> > > working directories screwed up a little too often:
> > >
> > > svn: Invalid change ordering: new node revision ID without delete.
> > >
> > > Well - I sure as hell typed the commands in the right order, it's not
> too
> > > hard: svn mv a b.
> > >
> > > How many other people have had to check out a new working copy and copy
> > > changes over and commit because their working copy was broken _again_
> > > without any explanation provided and a cryptic error message that
> doesn't
> > > really explain what the problem actualy is?
> > >
> > > Is there any hope that Subversion will improve on the current state of
> > > affairs or should we all be looking to shell out for a commercial scm
> that
> > > works more often?
> >
> > Unfortunately, you've hit a bug. Sorry, it happens, even in
> > commercial scms. Welcome to the real world, where things are
> > occasionally imperfect.
>
>
> I don't know if this is helpfull at all but accurev keeps a log of all the
> things that have happened to the repo and to the working copy so that if a
> problem arrises you can just mail the log to the developers and they can
> figure out what happened. Would it be usefull if svn had something similar?
Sure, that would be an interesting feature. If you feel like adding
it I'd love to see a proposal discussed on the dev@ list.
> > If you can provide a sequence of commands that gets your repository
> > and working copy into that state ( i.e. something that starts from an
> > empty repository and makes it happen) I'll be happy to look into
> > fixing the problem. Unfortunately, you haven't actually provided much
> > information in your email other than "I get this weird error when I do
> > something", so it's rather difficult for me to determine what the
> > problem is based on it.
>
>
> I do appreciate that SCM is a very very difficult problem to solve well, and
> svn does a pretty good job overall, which I do appreciate. It sure is a
> hell of alot better than CVS or VSS!
Thanks ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 31 03:35:39 2006