Johan Corveleyn gmail.com> writes:
> 'svn cleanup' removes any working copy locks, and runs whatever is
> left in the work_queue, thereby returning the working copy to a valid
> state.
>
> BTW, the work of moving the file into place has some sort of
> "retry-loop", where it keeps retrying for a c
- Original Message -
> From: Stefan Sperling
>
> AFAIK open files cannot be deleted on Windows. So either the file was closed
> at the time the 1.6 wc log was run, or the 1.6 wc log failed to actually
> update the on-disk data.
No no no :) neither nor.
1.6 just tested the file _before_
On Sat, Jun 16, 2012 at 01:55:18AM +0100, Philip Martin wrote:
> There is also a 1.6 bug:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4196
>
> that removes locks that should remain.
>
> I think it is likely that Justin is seeing the buggy 1.6 behaviour. In
> some circumstances this
Guten Tag Justin Case,
am Samstag, 16. Juni 2012 um 03:33 schrieben Sie:
> Please guys, don't keep using the word "locks" then throwing it
> back at me: I'm NOT EXPERIENCING LOCKS, just a regular file being in
> use in Windows.
Calm down, there's more than one type of a lock and just because you
- Original Message -
>
> I'm not sure whether that applies to Justin's particular case because
> that's only a problem if the lock gets released between the original
> workqueue run and the second workqueue run. That's a very small
> window--in most cases both runs see the lock and the b
Stefan Sperling writes:
> I don't know if Justin's particular case could somehow be detected and
> handled in a more automated fashion. But it would be nice if svn did this.
> Justin, if you care strongly about this, please add an entry to our issue
> tracker[1] that points at this thread in the
On Wed, Jun 13, 2012 at 10:17:02AM -0500, Les Mikesell wrote:
> On Wed, Jun 13, 2012 at 7:12 AM, Johan Corveleyn wrote:
> > The problem is that, at the point where svn runs into this locked
> > file, half of the work has already been done (the metadata in wc.db
> > has already been updated). The r
- Original Message -
>
> But as said before, that's possibly quite hard to achieve
> in light of an existing possibly multi-layered implementation
No idea what you mean with multi-layers - wc.db and such are internal issues of
svn, of which nobody above should be made aware. I think. At
On Wed, Jun 13, 2012 at 7:12 AM, Johan Corveleyn wrote:
>
>> Why should I have to cleanup???
>> svn update (see point 2) KNEW the file is in use, so instead of leaving
>> locks around it could just have skipped that file and print a message that
>> not everything have been updated.
>
> The probl
On Wed, Jun 13, 2012 at 02:12:47PM +0200, Johan Corveleyn wrote:
> On Wed, Jun 13, 2012 at 12:20 PM, Justin Case
> wrote:
> > Why should I have to cleanup???
> > svn update (see point 2) KNEW the file is in use, so instead of leaving
> > locks around it could just have skipped that file and print
On Wed, Jun 13, 2012 at 2:25 PM, Justin Case
wrote:
>
>
>> From: Johan Corveleyn
>>
>> The problem is that, at the point where svn runs into this locked
>> file, half of the work has already been done (the metadata in wc.db
>> has already been updated). The remaining work (moving the file into
>>
> From: Johan Corveleyn
>
> The problem is that, at the point where svn runs into this locked
> file, half of the work has already been done (the metadata in wc.db
> has already been updated). The remaining work (moving the file into
> place) is scheduled in a specific table called the work_que
On Wed, Jun 13, 2012 at 12:20 PM, Justin Case
wrote:
> - Original Message -
>
>> From: Ulrich Eckhardt
>>
>> Sorry, but I'm afraid I didn't get across what I wanted to say.
>
> Correct. Let me simplify again my test case:
> 1. I run svn update
> 2. svn update finds a file in use, aborts
>
On Wed, Jun 13, 2012 at 6:20 AM, Justin Case wrote:
> - Original Message -
>
> > From: Ulrich Eckhardt
> >
> > Sorry, but I'm afraid I didn't get across what I wanted to say.
>
> Correct. Let me simplify again my test case:
> 1. I run svn update
> 2. svn update finds a file in use, abort
- Original Message -
> From: Ulrich Eckhardt
>
> Sorry, but I'm afraid I didn't get across what I wanted to say.
Correct. Let me simplify again my test case:
1. I run svn update
2. svn update finds a file in use, aborts
3. I free the file, oops it seems I have to cleanup
Why should I
Am 12.06.2012 16:49, schrieb Justin Case:
> - Original Message -
>> From: Ulrich Eckhardt Yes,
>> probably, unless it was killed so quickly that it couldn't even
>> cry for help any more, which e.g. happens if you cut the power or
>> use "kill -9" on POSIX systems.
>
> We're not talking h
- Original Message -
> From: Ulrich Eckhardt
> Yes, probably, unless it was killed so quickly that it couldn't even cry
> for help any more, which e.g. happens if you cut the power or use "kill
> -9" on POSIX systems.
We're not talking here about natural catastrophes, but about a file w
Am 12.06.2012 15:43, schrieb Justin Case:
>> From: Ulrich Eckhardt
>>
>> Only you (the user) knows "if it was interrupted" or is maybe
>> still running! I would say that this message could be improved[0],
>> but
>
> I beg to differ: the operation which interrupted itself because it
> found a fil
Hi,
On Tue, Jun 12, 2012 at 06:43:52AM -0700, Justin Case wrote:
> > From: Ulrich Eckhardt
> >
> > Only you (the user) knows "if it was interrupted" or is maybe still
> > running! I would say that this message could be improved[0], but
>
> I beg to differ: the operation which interrupted itself
> From: Ulrich Eckhardt
>
> Only you (the user) knows "if it was interrupted" or is maybe still
> running! I would say that this message could be improved[0], but
I beg to differ: the operation which interrupted itself because it found a file
in use knows very well that it was interrupted. So, i
Am 12.06.2012 13:52, schrieb Justin Case:
> In any case, I certainly hope the new version doesn't expect from me,
> the user, telling it whether the lock is a stale one or if there's
> some other command hanging on it...
Put that into the context of the error message:
> Update
> Previous operatio
On Tue, Jun 12, 2012 at 1:52 PM, Justin Case
wrote:
>> From: Johan Corveleyn
>
>>
>> cleanup' (cleanup is the only command that will unconditionally remove
>> these locks, so you should only run it if you're sure there is no
>> other command running concurrently, and those locks are "stale locks"
> From: Johan Corveleyn
>
> cleanup' (cleanup is the only command that will unconditionally remove
> these locks, so you should only run it if you're sure there is no
> other command running concurrently, and those locks are "stale locks"
> left by other interrupted commands).
> [...]
> I don't f
On Tue, 12 Jun 2012 12:26:34 +, Johan Corveleyn wrote:
...
> > - BUT I cannot update again, I have to cleanup first!
>
> This seems normal too. Before doing anything, 'svn update' will lock
> the working copy (to prevent any concurrent svn actions from messing
> with it while it's updating). I
On Wed, Jun 6, 2012 at 1:14 PM, Justin Case
wrote:
> Hi all,
> this is something new for me (TortoiseSVN 1.7.7 with Subversion 1.7.5 on
> Windows XP):
> - I try to update something when a file is in use,
> - update understandably fails, it cannot overwrite that file. Fine.
This is indeed normal,
Hello all,
did I just ask a stupid question :) or nobody has any idea what's going wrong
here?
Thank you very much for your patience,
JJ
- Original Message -
> From: Justin Case
>
> Hi all,
> this is something new for me (TortoiseSVN 1.7.7 with Subversion 1.7.5 on
> Windows
> XP):
Hi all,
this is something new for me (TortoiseSVN 1.7.7 with Subversion 1.7.5 on
Windows XP):
- I try to update something when a file is in use,
- update understandably fails, it cannot overwrite that file. Fine.
- BUT I cannot update again, I have to cleanup first!
Before days (months?) the clean
27 matches
Mail list logo
