You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dan Allen <da...@mojavelinux.com> on 2003/04/28 05:13:36 UTC
really, really force please!!!
Argh, I am going to throw a fit if I get one more "file is out of
date" error. Would there be any way to add a
"--really-really-force" option so that you just don't get an error
message. I am the only person committing to the repository yet I
consistently get out of date errors, and I just don't see how.
Please consider adding a user override for this. Nothing is more
frustrating then spending more time trying to commit then editing
the files. Hopefully you see where I am coming from here.
Dan
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Daniel Allen, <da...@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
It is not enough to succeed. Others must fail.
-- Gore Vidal
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: really, really force please!!!
Posted by Branko Čibej <br...@xbc.nu>.
Dan Allen wrote:
>Argh, I am going to throw a fit if I get one more "file is out of
>date" error. Would there be any way to add a
>"--really-really-force" option so that you just don't get an error
>message.
>
How about a --really-really-break-my-repository option? It comes to
about the same thing
> I am the only person committing to the repository yet I
>consistently get out of date errors, and I just don't see how.
>
Please tell me you don't have a post-commit hook that commits something
to the repository.
>Please consider adding a user override for this. Nothing is more
>frustrating then spending more time trying to commit then editing
>the files. Hopefully you see where I am coming from here.
>
>
No. There already is a user override here: it's called "svn update". And
I prophesy that you're not the only one committing to the repository.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by "Sergey A. Lipnevich" <se...@pisem.net>.
Branko Čibej wrote:
>>a good version control system should let the user decide what is used
>>to decide if a file is "new" or "changed".
>>
>
> No! Definitely, absolutely not. Only the version control system knows
> what's up-to-date. Ignoring conflicts during commit is a recipe for
> disaster; sooner or later somebody will destroy someone else's changes.
>
FWIW, I wholeheartedly agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Branko Čibej <br...@xbc.nu>.
Dan Allen wrote:
>>The errors he's talking about are caused by something being committed to
>>the file between his commits. The server knows that, and will not allow
>>a commit without an update first.
>>
>>
>
>Well let me jump from here. I mentioned to the list that somehow
>the repository gets "out of sync" complaining that there is a newer
>file on the server when I know for a fact there is not because not
>only am I the only one committing right now (no I do not have a
>post-commit hook because I am evaluating svn and I want to make sure
>that it can work for us at the very primitive level first before
>getting fancy). I do an svn update but it just says the repository
>version number and ends, meaning there are no new updates, but when
>I go to commit, it won't go. I even touch and change the file I am
>committing, still no dice. The clocks are pretty much the same on
>both server in client (maybe only off by a half a minute a most).
>Do I think in the long run there should be a force that might break
>the repository, probably not. Is it necessary while this bug
>exists....it would be helpful.
>
>Client: 0.20.1
>Server: 0.20.1
>
>
Well, can you please tell us which platform you're using, where you got
the SVN binaries or how you compiled them, and the exact command
sequence (including repository creation) that lets you reproduce this
problem? The fact is, we have a zillion tests that do exactly what you
claim you're doing, and they pass on quite a few platforms.
As Garrett said, without a detailed bug report, we can't even begin to
gues what's going on.
And no, there should not be a --force that hides bugs, if this is indeed
a bug. Such an option is just plain wrong. If it's a user error, then
it's even wronger.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Dan Allen <da...@mojavelinux.com>.
> Dan, this bug is unheard of. Nobody has ever seen it, or experienced
> it, or can reproduce it. We're not interested in coming up with UI
> workarounds; we're interested in figuring out what's happening to you,
> because the problem you're experiencing is so incredibly, so
> fundamentally broken. I can hardly believe it's happening to you.
>
> Give us a step-by-step reproduction recipe that causes the bug for
> you. Something like:
>
> $ svnadmin create repos
> $ svn co file://`pwd`/repos wc
> $ cd wc
> $ touch foo; svn add foo
> $ svn commit -m "adding foo"
> $ echo "blah" >> foo
> $ svn commit -m "changing foo"
> $ echo "blah2" >> foo
> $ svn commit -m "changing foo again"
>
> ...or whatever.
Okay, I will do my best to try to give you a detailed problem
report. Please understand however that I am in mid stride on two due
dates in the next two days and when this started to happen needless
to say I got a little stressed. I know you cannot work without the
right information and I will do my best to provide that. I am just
getting a lot of heat right now because "my svn" is running into
issues and I obviously have no answer to give. You know how it gets
in the office place. Look for a report soon.
Dan
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Daniel Allen, <da...@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Real programmers just hate to get up in the morning, and
contrary to Ordinary People, they're in better shape as
it gets closer to nighttime.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Ben Collins-Sussman <su...@collab.net>.
Dan Allen <da...@mojavelinux.com> writes:
> Do I think in the long run there should be a force that might break
> the repository, probably not. Is it necessary while this bug
> exists....it would be helpful.
>
> Client: 0.20.1
> Server: 0.20.1
Dan, this bug is unheard of. Nobody has ever seen it, or experienced
it, or can reproduce it. We're not interested in coming up with UI
workarounds; we're interested in figuring out what's happening to you,
because the problem you're experiencing is so incredibly, so
fundamentally broken. I can hardly believe it's happening to you.
Give us a step-by-step reproduction recipe that causes the bug for
you. Something like:
$ svnadmin create repos
$ svn co file://`pwd`/repos wc
$ cd wc
$ touch foo; svn add foo
$ svn commit -m "adding foo"
$ echo "blah" >> foo
$ svn commit -m "changing foo"
$ echo "blah2" >> foo
$ svn commit -m "changing foo again"
...or whatever.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Dan Allen <da...@mojavelinux.com> writes:
> Do I think in the long run there should be a force that might break
> the repository, probably not. Is it necessary while this bug
> exists....it would be helpful.
No -- we need to fix this serious bug (which we've never seen before).
The more reproduction details the have, the sooner we'll be able to do
so.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by mark benedetto king <mb...@boredom.org>.
On Tue, Apr 29, 2003 at 07:33:37AM +0200, Branko ??ibej wrote:
> mark benedetto king wrote:
>
> >On Mon, Apr 28, 2003 at 12:51:50PM -0500, cmpilato@collab.net wrote:
> >
> >
> >>To assume the .svn is bogus is to practically require a checkout. I
> >>mean, what else is checkout but the creation of a bunch of .svn
> >>directories plus the addition copy-and-translation of a pristine
> >>text-base out into the working file area?
> >>
> >>
> >Well, we *do* know what the checksums should be, which is why there's
> >issue 1177. I don't recall whether 1177 mentions that bogosity could
> >be repaired on-the-fly, but that's an obvious next-step.
> >
> >
> If we assume that .svn is corrupt, then we don't know what the checksums
> would be.
>
If the consistency of .svn as a whole is in doubt, then we cannot even
determine which revision(s) to obtain. I was thinking about the case where
somehow the text-base had become corrupt, but the metadata was still correct.
If .svn is not to be trusted, then it's probably most expedient to
find baddir -name .svn | xargs rm -rf
tar czvf /tmp/working-files.tgz baddir
svn co the appropriate revision
tar xzvf /tmp/working-files.tgz
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Branko Čibej <br...@xbc.nu>.
mark benedetto king wrote:
>On Mon, Apr 28, 2003 at 12:51:50PM -0500, cmpilato@collab.net wrote:
>
>
>>To assume the .svn is bogus is to practically require a checkout. I
>>mean, what else is checkout but the creation of a bunch of .svn
>>directories plus the addition copy-and-translation of a pristine
>>text-base out into the working file area?
>>
>>
>Well, we *do* know what the checksums should be, which is why there's
>issue 1177. I don't recall whether 1177 mentions that bogosity could
>be repaired on-the-fly, but that's an obvious next-step.
>
>
If we assume that .svn is corrupt, then we don't know what the checksums
would be.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by mark benedetto king <mb...@boredom.org>.
On Mon, Apr 28, 2003 at 12:51:50PM -0500, cmpilato@collab.net wrote:
> solo turn <so...@yahoo.com> writes:
>
> > there is no "svn repair-working-copy" command, which assumes the
> > contents of .svn is damaged and recreates it, isn't it?
> >
> > it would be the same as a "svn co" but just affecting the .svn dirs.
>
> To assume the .svn is bogus is to practically require a checkout. I
> mean, what else is checkout but the creation of a bunch of .svn
> directories plus the addition copy-and-translation of a pristine
> text-base out into the working file area?
>
Well, we *do* know what the checksums should be, which is why there's
issue 1177. I don't recall whether 1177 mentions that bogosity could
be repaired on-the-fly, but that's an obvious next-step.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by cm...@collab.net.
solo turn <so...@yahoo.com> writes:
> there is no "svn repair-working-copy" command, which assumes the
> contents of .svn is damaged and recreates it, isn't it?
>
> it would be the same as a "svn co" but just affecting the .svn dirs.
To assume the .svn is bogus is to practically require a checkout. I
mean, what else is checkout but the creation of a bunch of .svn
directories plus the addition copy-and-translation of a pristine
text-base out into the working file area?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by solo turn <so...@yahoo.com>.
there is no "svn repair-working-copy" command, which assumes the
contents of .svn is damaged and recreates it, isn't it?
it would be the same as a "svn co" but just affecting the .svn dirs.
--- Dan Allen <da...@mojavelinux.com> wrote:
> > The errors he's talking about are caused by something being
> committed to
> > the file between his commits. The server knows that, and will not
> allow
> > a commit without an update first.
>
> Well let me jump from here. I mentioned to the list that somehow
> the repository gets "out of sync" complaining that there is a newer
> file on the server when I know for a fact there is not because not
> only am I the only one committing right now (no I do not have a
> post-commit hook because I am evaluating svn and I want to make
> sure
> that it can work for us at the very primitive level first before
> getting fancy). I do an svn update but it just says the repository
> version number and ends, meaning there are no new updates, but when
> I go to commit, it won't go. I even touch and change the file I am
> committing, still no dice. The clocks are pretty much the same on
> both server in client (maybe only off by a half a minute a most).
> Do I think in the long run there should be a force that might break
> the repository, probably not. Is it necessary while this bug
> exists....it would be helpful.
>
> Client: 0.20.1
> Server: 0.20.1
>
> Dan
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Daniel Allen, <da...@mojavelinux.com>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "I'm old enough to know better, but still too young to care."
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Dan Allen <da...@mojavelinux.com>.
> The errors he's talking about are caused by something being committed to
> the file between his commits. The server knows that, and will not allow
> a commit without an update first.
Well let me jump from here. I mentioned to the list that somehow
the repository gets "out of sync" complaining that there is a newer
file on the server when I know for a fact there is not because not
only am I the only one committing right now (no I do not have a
post-commit hook because I am evaluating svn and I want to make sure
that it can work for us at the very primitive level first before
getting fancy). I do an svn update but it just says the repository
version number and ends, meaning there are no new updates, but when
I go to commit, it won't go. I even touch and change the file I am
committing, still no dice. The clocks are pretty much the same on
both server in client (maybe only off by a half a minute a most).
Do I think in the long run there should be a force that might break
the repository, probably not. Is it necessary while this bug
exists....it would be helpful.
Client: 0.20.1
Server: 0.20.1
Dan
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Daniel Allen, <da...@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"I'm old enough to know better, but still too young to care."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: user decides what to use as file-compare
Posted by Branko Čibej <br...@xbc.nu>.
solo turn wrote:
>i think dan is right here:
>
>a good version control system should let the user decide what is used
>to decide if a file is "new" or "changed".
>
No! Definitely, absolutely not. Only the version control system knows
what's up-to-date. Ignoring conflicts during commit is a recipe for
disaster; sooner or later somebody will destroy someone else's changes.
> options include:
>- date/time
>- checksum
> (and this is the only case where i would actually
> care that it is a cryptographically good checksum)
>- contents
>or a combinantion of the above.
>
The errors he's talking about are caused by something being committed to
the file between his commits. The server knows that, and will not allow
a commit without an update first.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
user decides what to use as file-compare (was: really, really force please!!!)
Posted by solo turn <so...@yahoo.com>.
i think dan is right here:
a good version control system should let the user decide what is used
to decide if a file is "new" or "changed". options include:
- date/time
- checksum
(and this is the only case where i would actually
care that it is a cryptographically good checksum)
- contents
or a combinantion of the above.
this information can be retrieved from the server, or from the .svn
folder, which also the user wants to decide (and with this option the
issue "my working copy is too big, but my server is fast" is a
non-issue).
-s.
--- mark benedetto king <mb...@boredom.org> wrote:
> On Mon, Apr 28, 2003 at 06:49:37AM -0400, Garrett Rooney wrote:
> >
> > On Monday, April 28, 2003, at 01:13 AM, Dan Allen wrote:
> >
> > >Argh, I am going to throw a fit if I get one more "file is out
> of
> > >date" error. Would there be any way to add a
> > >"--really-really-force" option so that you just don't get an
> error
> > >message. I am the only person committing to the repository yet
> I
> > >consistently get out of date errors, and I just don't see how.
> > >Please consider adding a user override for this. Nothing is
> more
> > >frustrating then spending more time trying to commit then
> editing
> > >the files. Hopefully you see where I am coming from here.
> >
> > you've mentioned this 'file is out of date' problem several
> times, and
> > i get the impression you think it's a bug, but i still haven't
> seen a
> > simple set of steps to reproduce it. if you can give us a
> transcript
> > of the commands you need to run to get this behavior on a clean
> > repository, i'm sure people would be happy to either point out
> why the
> > behavior is needed, or fix the bug.
>
> Exactly. Adding the option would be addressing the symptom rather
> than
> the cause.
>
> --ben
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: really, really force please!!!
Posted by mark benedetto king <mb...@boredom.org>.
On Mon, Apr 28, 2003 at 06:49:37AM -0400, Garrett Rooney wrote:
>
> On Monday, April 28, 2003, at 01:13 AM, Dan Allen wrote:
>
> >Argh, I am going to throw a fit if I get one more "file is out of
> >date" error. Would there be any way to add a
> >"--really-really-force" option so that you just don't get an error
> >message. I am the only person committing to the repository yet I
> >consistently get out of date errors, and I just don't see how.
> >Please consider adding a user override for this. Nothing is more
> >frustrating then spending more time trying to commit then editing
> >the files. Hopefully you see where I am coming from here.
>
> you've mentioned this 'file is out of date' problem several times, and
> i get the impression you think it's a bug, but i still haven't seen a
> simple set of steps to reproduce it. if you can give us a transcript
> of the commands you need to run to get this behavior on a clean
> repository, i'm sure people would be happy to either point out why the
> behavior is needed, or fix the bug.
Exactly. Adding the option would be addressing the symptom rather than
the cause.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: really, really force please!!!
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Monday, April 28, 2003, at 01:13 AM, Dan Allen wrote:
> Argh, I am going to throw a fit if I get one more "file is out of
> date" error. Would there be any way to add a
> "--really-really-force" option so that you just don't get an error
> message. I am the only person committing to the repository yet I
> consistently get out of date errors, and I just don't see how.
> Please consider adding a user override for this. Nothing is more
> frustrating then spending more time trying to commit then editing
> the files. Hopefully you see where I am coming from here.
you've mentioned this 'file is out of date' problem several times, and
i get the impression you think it's a bug, but i still haven't seen a
simple set of steps to reproduce it. if you can give us a transcript
of the commands you need to run to get this behavior on a clean
repository, i'm sure people would be happy to either point out why the
behavior is needed, or fix the bug.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org