Oh - server fs is FSFS I believe
ALex
On 7/30/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>
> 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
>
Received on Mon Jul 31 03:37:44 2006