You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alex Turner <ar...@gmail.com> on 2006/07/31 01:01:26 UTC
Working Copy in Inconsistent State
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?
Alex.
Re: Working Copy in Inconsistent State
Posted by Alex Turner <ar...@gmail.com>.
Oh - server fs is FSFS I believe
ALex
On 7/30/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
> On 7/30/06, Alex Turner <ar...@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
>
Re: Working Copy in Inconsistent State
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/30/06, Alex Turner <ar...@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
Re: Working Copy in Inconsistent State
Posted by Alex Turner <ar...@gmail.com>.
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 ;).
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.
I don't know how much help that is.
(more comments further down...)
On 7/30/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
> On 7/30/06, Alex Turner <ar...@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?
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!
-garrett
>
Thanks,
Alex
Re: Working Copy in Inconsistent State
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/30/06, Alex Turner <ar...@gmail.com> wrote:
> Alas thats a bit tricky to do on a RedHat system and still keep things sane.
> At least ES 5 is due out next month.
There are third party RPMs that have been built for older versions of
RedHat, FWIW.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: Alex Turner
To: Garrett Rooney
Cc: Nico Kadel-Garcia ; users@subversion.tigris.org
Sent: Sunday, July 30, 2006 9:52 PM
Subject: Re: Working Copy in Inconsistent State
Alas thats a bit tricky to do on a RedHat system and still keep things sane. At least ES 5 is due out next month.
Alex.
It's actually pretty straightforward: Subversion is pretty good about backwards compatibility, and there are some good RPM's available on David Summers website, at http://summersoft.fay.ar.us/pub/subversion/latest/. The RHEL3 backages only support an FSFS backend, and I think that's wise.
Re: Working Copy in Inconsistent State
Posted by Alex Turner <ar...@gmail.com>.
Alas thats a bit tricky to do on a RedHat system and still keep things
sane. At least ES 5 is due out next month.
Alex.
On 7/30/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
> On 7/30/06, Alex Turner <ar...@gmail.com> wrote:
> > Sorry - that might have been usefull:
> >
> > Client OS: RedHat ES 4 (Nahant Update 3), linux 2.6.9-34.EL.smp, svn
> 1.1.4
> > (r13838) on Dual CPU AMD Opteron
> >
> > Server OS: RedHat ES 4 (Nahant Update 3), linux 2.6.9-34 EL, svn 1.1.4
> > (r13838) on Single CPU Celeron, using svnserve to access remotely.
> >
> > (yeah the server is a POS compared to the client, long story to do with
> who
> > owns what and stuff).
>
> Well, considering that you're using a version of Subversion that's
> over a year old (and at least two minor version revs out of date) the
> first thing I'd recommend is updating to a more current version (1.3.x
> most likely, as it's the current release version) on both the client
> and server. If that doesn't fix the problem, I'd love to see if you
> can reproduce it with a 1.4.x release candidate, but it's a bit harder
> to recommend that if you can't reproduce it outside your production
> environment since it's not a real released version of svn.
>
> -garrett
>
Re: Working Copy in Inconsistent State
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/30/06, Alex Turner <ar...@gmail.com> wrote:
> Sorry - that might have been usefull:
>
> Client OS: RedHat ES 4 (Nahant Update 3), linux 2.6.9-34.EL.smp, svn 1.1.4
> (r13838) on Dual CPU AMD Opteron
>
> Server OS: RedHat ES 4 (Nahant Update 3), linux 2.6.9-34 EL, svn 1.1.4
> (r13838) on Single CPU Celeron, using svnserve to access remotely.
>
> (yeah the server is a POS compared to the client, long story to do with who
> owns what and stuff).
Well, considering that you're using a version of Subversion that's
over a year old (and at least two minor version revs out of date) the
first thing I'd recommend is updating to a more current version (1.3.x
most likely, as it's the current release version) on both the client
and server. If that doesn't fix the problem, I'd love to see if you
can reproduce it with a 1.4.x release candidate, but it's a bit harder
to recommend that if you can't reproduce it outside your production
environment since it's not a real released version of svn.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Alex Turner <ar...@gmail.com>.
Sorry - that might have been usefull:
Client OS: RedHat ES 4 (Nahant Update 3), linux 2.6.9-34.EL.smp, svn
1.1.4(r13838) on Dual CPU AMD Opteron
Server OS: RedHat ES 4 (Nahant Update 3), linux 2.6.9-34 EL, svn
1.1.4(r13838) on Single CPU Celeron, using svnserve to access
remotely.
(yeah the server is a POS compared to the client, long story to do with who
owns what and stuff).
Alex
On 7/30/06, Nico Kadel-Garcia <nk...@comcast.net> wrote:
>
>
> ----- Original Message -----
> From: "Garrett Rooney" <ro...@electricjellyfish.net>
> To: "Alex Turner" <ar...@gmail.com>
> Cc: <us...@subversion.tigris.org>
> Sent: Sunday, July 30, 2006 9:12 PM
> Subject: Re: Working Copy in Inconsistent State
>
>
> > On 7/30/06, Alex Turner <ar...@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.
> >
> > 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.
> >
> > -garrett
>
> In particular, describing the Subversion versions of your client and your
> server, and the OS on each of them, may be a big help. As a user and
> programmer, I note that making checkouts atomic is a very, very different
> problem than making checkins atomic, and I can easily beliave that some
> subtlety is interfering with your work.
>
> In particluar, are you using MacOS? There are some serious weirdnesses
> with
> resource forks that can be very tough to deal with.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Working Copy in Inconsistent State
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Ryan Schmidt wrote:
> On Jul 31, 2006, at 03:30, Nico Kadel-Garcia wrote:
>
>>> On Jul 31, 2006, at 03:20, Nico Kadel-Garcia wrote:
>>>
>>>> In particluar, are you using MacOS? There are some serious
>>>> weirdnesses with resource forks that can be very tough to deal
>>>> with.
>>>
>>> What? Subversion makes no use of resource forks. Subversion on Mac
>>> OS X should behave quite similarly to Subversion on *BSD or
>>> Linux, from everything I've seen.
>>
>> I thought there were some reports here of difficulties when "svm
>> move"ing files?
>
> Perhaps you're thinking of this thread?
>
> http://svn.haxx.se/users/archive-2006-05/0907.shtml
Bingo. That's exactly what I meant, although you went into it in lovely
detail.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 31, 2006, at 03:30, Nico Kadel-Garcia wrote:
>> On Jul 31, 2006, at 03:20, Nico Kadel-Garcia wrote:
>>
>>> In particluar, are you using MacOS? There are some serious
>>> weirdnesses with resource forks that can be very tough to deal with.
>>
>> What? Subversion makes no use of resource forks. Subversion on Mac
>> OS X should behave quite similarly to Subversion on *BSD or
>> Linux, from everything I've seen.
>
> I thought there were some reports here of difficulties when "svm
> move"ing files?
Perhaps you're thinking of this thread?
http://svn.haxx.se/users/archive-2006-05/0907.shtml
The problem was/is that for single-fork filesystems like UFS (or if
you have a working copy on a Samba share for example) then the
resource forks are represented as files whose names are "._" plus the
file's real name. But as of Mac OS X 10.4 Apple "helpfully"
automatically moves these files when you tell the OS to move the real
file. If both files are under Subversion's control, then you run into
errors when Subversion tries to move the "._" file but has already
moved the real file and the "._" file isn't where Subversion thinks
it is anymore. On the one hand it's Apple's fault for being too
helpful, and on the other hand it could be resolved by Subversion
doing file operations in alphabetical (instead of essentially random)
order.
In any case, Subversion doesn't know about the resource fork and like
most CLI programs it will deal with files as data-fork only. When
used on Mac OS X's default multifork filesystem, HFS+, things
therefore work pretty well, for files that don't need resource forks.
If you check in a file, only its data fork gets checked in. When you
check out or update somewhere else, only the data fork will arrive.
And this is fine for most modern file formats where the resource fork
is optional (like my text editor which just uses the resource fork to
store editor settings like text font and size, window size and
position, and so forth -- which could be considered optional/
nonessential information so it's no problem this data is lost on
checkin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Ryan Schmidt" <su...@ryandesign.com>
To: "Nico Kadel-Garcia" <nk...@comcast.net>
Cc: "Subversion List" <us...@subversion.tigris.org>
Sent: Sunday, July 30, 2006 9:25 PM
Subject: Re: Working Copy in Inconsistent State
>
> On Jul 31, 2006, at 03:20, Nico Kadel-Garcia wrote:
>
>> In particluar, are you using MacOS? There are some serious weirdnesses
>> with resource forks that can be very tough to deal with.
>
> What? Subversion makes no use of resource forks. Subversion on Mac OS X
> should behave quite similarly to Subversion on *BSD or Linux, from
> everything I've seen.
I thought there were some reports here of difficulties when "svm move"ing
files?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 31, 2006, at 03:20, Nico Kadel-Garcia wrote:
> In particluar, are you using MacOS? There are some serious
> weirdnesses with resource forks that can be very tough to deal with.
What? Subversion makes no use of resource forks. Subversion on Mac OS
X should behave quite similarly to Subversion on *BSD or Linux, from
everything I've seen.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Garrett Rooney" <ro...@electricjellyfish.net>
To: "Alex Turner" <ar...@gmail.com>
Cc: <us...@subversion.tigris.org>
Sent: Sunday, July 30, 2006 9:12 PM
Subject: Re: Working Copy in Inconsistent State
> On 7/30/06, Alex Turner <ar...@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.
>
> 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.
>
> -garrett
In particular, describing the Subversion versions of your client and your
server, and the OS on each of them, may be a big help. As a user and
programmer, I note that making checkouts atomic is a very, very different
problem than making checkins atomic, and I can easily beliave that some
subtlety is interfering with your work.
In particluar, are you using MacOS? There are some serious weirdnesses with
resource forks that can be very tough to deal with.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working Copy in Inconsistent State
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/30/06, Alex Turner <ar...@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.
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.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org