AW: subversion destroys my Working Copy

[Daniel Migowski]

Hello Andreas,

my editor (current Eclipse 4.4) locks my build.xml files, even after I closed 
them in the Editor. This is a bug, alright, but nonetheless I feel that 
subversion should never leave the Working Copy in a state where it cannot be 
cleaned up anymore.

I propose the following behavior as correct: Since the commit itself succeeded, 
the local file should be marked as being in the revision committed, but with 
local changes (since the tags have not been updated). Then I could simply fix 
my problems by reverting to HEAD after unlocking my file and everything is fine.

Do you agree? This behaviors seems much better.

Regards,
Daniel Migowski

Von: Andreas Stieger [mailto:andreas.stie...@gmx.de]
Gesendet: Donnerstag, 17. Juli 2014 07:44
An: Daniel Migowski
Cc: users@subversion.apache.org
Betreff: Re: subversion destroys my Working Copy

Hi,

On 17 Jul 2014, at 02:41, Daniel Migowski 
mailto:dmigow...@ikoffice.de>> wrote:
This always occurs when I commit a resource already open in an editor which 
contains a @revision tag. The commit message looks like this:

C:\IKOfficeRoot\Java\ERP\Core\build.xml
C:\IKOfficeRoot\Java\ERP\Framework\data\templates\customer-build-template.xml
C:\IKOfficeRoot\Java\ERP\Core\build.xml
C:\IKOfficeRoot\Java\ERP\Framework\data\templates\customer-build-template.xml
At revision: 28113
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
Failed to run the WC DB work queue associated with 'C:\IKOfficeRoot', work item 
48025 (file-commit Java/ERP/Core/build.xml)
Can't move 'C:\IKOfficeRoot\.svn\tmp\svn-F4D69508' to 
'C:\IKOfficeRoot\Java\ERP\Core\build.xml': Zugriff verweigert

Environmental problem, the file is locked. Which editor are you using? Does 
your editor lock files in a way that is incompatible with modifications via 
keywords? Does the same happen if you close the editor when committing?

I beg you to fix that because it is really time consuming and annoying having 
to check out gigabytes again and again.

There is ways around that, including partial checkout. Also working copies are 
portable and can be cloned.


And just in case you wonder: Of couse I tried to cleanup the root folder 
C:\IKOfficeRoot, but this always tells me that cleanup doesn’t succeed, and 
that I should do a cleanup instead…

As above, check if your environment locks files in ways that would cause his 
behaviour.

Andreas

RE: Unexpected merge result

[David Aldrich]

A little more information:

It seems that the property change is actually the removal of property 
svn:mergeinfo.

David


From: David Aldrich [mailto:david.aldr...@emea.nec.com]
Sent: 16 July 2014 16:04
To: 'users@subversion.apache.org' (users@subversion.apache.org)
Subject: Unexpected merge result

Hi

I am running a svn 1.8.9 client on Windows against a 1.8.9 server.

Today I created a new branch from my trunk and made some changes to the branch. 
I want to merge those changes back to the trunk. The trunk has not been changed 
since creating the branch.

First I did a merge from trunk to branch, expecting nothing to merge, but one 
file did change:

C:\>svn status
X   \dsp_include

Performing status on external item at '\dsp_include':

C:\>svn merge ^^/trunk
--- Recording mergeinfo for merge of r5824 through r5827 into '.':
U   .
--- Eliding mergeinfo from '\StarCoMPLTE.h':
U   \StarCoMPLTE.h

C:\SVNProj\zodiac\branches\TRY_NECA_SBM_16July2014>svn status
M  .
X   \dsp_include
M  \StarCoMPLTE.h

The change to StarCoMPLTE.h is to properties only but I don't why the 
properties have changed since nothing changed on the trunk.

Is this a bug?  How should I handle this please?

Best regards

David


Click 
here
 to report this email as spam.

[no subject]

[Jacky wong]

Re: subversion destroys my Working Copy

[Johan Corveleyn]

On Thu, Jul 17, 2014 at 11:23 AM, Daniel Migowski  wrote:
> Hello Andreas,
>
>
>
> my editor (current Eclipse 4.4) locks my build.xml files, even after I
> closed them in the Editor. This is a bug, alright, but nonetheless I feel
> that subversion should never leave the Working Copy in a state where it
> cannot be cleaned up anymore.
>
>
>
> I propose the following behavior as correct: Since the commit itself
> succeeded, the local file should be marked as being in the revision
> committed, but with local changes (since the tags have not been updated).
> Then I could simply fix my problems by reverting to HEAD after unlocking my
> file and everything is fine.
>
>
>
> Do you agree? This behaviors seems much better.
>

Just as a FYI, some prior discussion around a similar issue (with 'svn revert'):

http://svn.haxx.se/users/archive-2014-02/0157.shtml ("svn revert"
corrupts working copy)

>From that discussion I remembered two things:

1) Your working copy isn't really corrupt. There is an obstruction
(locked file in your case) that prevents svn from completing its work.
Remove the obstruction and all will be fine (after removing the
obstruction running 'svn cleanup' should bring everything back into a
consistent state).

2) With the current design, there is not much that can be done about
this. During its operation (update, revert, ...) svn makes changes to
both its database (.svn/wc.db) and the filesystem. Both parts need to
be consistent with each other. Svn will first make changes to its
database, and then schedule the changes it needs to make to the
filesystem in its "work queue" (things that still need to be completed
on the filesystem to bring the working copy in a consistent state). If
some part of the work queue cannot be completed (because of an
obstruction) svn will bail out. The work queue still needs to be
completed though, before anything else can be done. Running 'svn
cleanup' first tries to complete the work queue, and will also bail
out if it can't. The work queue *must* be completed to return the
working copy to a consistent state.


-- 
Johan

AW: subversion destroys my Working Copy

[Daniel Migowski]

Hello,

I have to say sorry for the noise. You were right, after retrying to cleanup my 
old copies of the working copy it occurred to me that subversion really can 
clean things up. The problem was that during my initial tests I didn't realize 
that Eclipse still held the lock when the editor was already closed. 

Sorry for that. 

Regards,
Daniel Migowski

-Ursprüngliche Nachricht-
Von: Johan Corveleyn [mailto:jcor...@gmail.com] 
Gesendet: Donnerstag, 17. Juli 2014 11:58
An: Daniel Migowski
Cc: Andreas Stieger; users@subversion.apache.org
Betreff: Re: subversion destroys my Working Copy

On Thu, Jul 17, 2014 at 11:23 AM, Daniel Migowski  wrote:
> Hello Andreas,
>
>
>
> my editor (current Eclipse 4.4) locks my build.xml files, even after I 
> closed them in the Editor. This is a bug, alright, but nonetheless I 
> feel that subversion should never leave the Working Copy in a state 
> where it cannot be cleaned up anymore.
>
>
>
> I propose the following behavior as correct: Since the commit itself 
> succeeded, the local file should be marked as being in the revision 
> committed, but with local changes (since the tags have not been updated).
> Then I could simply fix my problems by reverting to HEAD after 
> unlocking my file and everything is fine.
>
>
>
> Do you agree? This behaviors seems much better.
>

Just as a FYI, some prior discussion around a similar issue (with 'svn revert'):

http://svn.haxx.se/users/archive-2014-02/0157.shtml ("svn revert"
corrupts working copy)

From that discussion I remembered two things:

1) Your working copy isn't really corrupt. There is an obstruction (locked file 
in your case) that prevents svn from completing its work.
Remove the obstruction and all will be fine (after removing the obstruction 
running 'svn cleanup' should bring everything back into a consistent state).

2) With the current design, there is not much that can be done about this. 
During its operation (update, revert, ...) svn makes changes to both its 
database (.svn/wc.db) and the filesystem. Both parts need to be consistent with 
each other. Svn will first make changes to its database, and then schedule the 
changes it needs to make to the filesystem in its "work queue" (things that 
still need to be completed on the filesystem to bring the working copy in a 
consistent state). If some part of the work queue cannot be completed (because 
of an
obstruction) svn will bail out. The work queue still needs to be completed 
though, before anything else can be done. Running 'svn cleanup' first tries to 
complete the work queue, and will also bail out if it can't. The work queue 
*must* be completed to return the working copy to a consistent state.


--
Johan

Re: How to see all history of a deleted file without knowing the exact last revision?

[Ryan Schmidt]

On Jul 16, 2014, at 8:52 AM, Benjamin Fritz wrote:

> Actually, I was looking to answer this question on stackoverflow:
> http://stackoverflow.com/questions/24766535/how-to-tell-what-revision-a-folder-was-deleted-in
> 
> The person was asking how to find the revision a folder was deleted
> in, and they knew some really old revision where the folder was
> definitely present (example: revision 2000 out of 1 had the
> folder).
> 
> I thought this would be a great use for peg revisions! But this throws an 
> error:
> 
> svn log -r 1:HEAD http://example.com/svn/path/that/got/deleted@2000
> 
> This stops the log history at revision 2000, which makes it useless
> for finding changes (like a deletion) *after* the known revision:
> 
> svn log http://example.com/svn/path/that/got/deleted@2000
> 
> In the general case I might be interested in changes to a file that
> happened between when I know it was there and when it eventually got
> deleted (for example, maybe somebody not very good at SVN renamed a
> file without using SVN on some branch, removed the old filename, and
> then merged back while we continued making changes on trunk). Is it
> possible to find the changes from a known revision to the deletion
> point, without knowing the exact revision where the file got deleted?

Last I checked, you have to know the revision when it got deleted. You can find 
out by running "svn log -vq" on the parent directory.

Re: subversion destroys my Working Copy

[Nico Kadel-Garcia]

On Thu, Jul 17, 2014 at 6:03 AM, Daniel Migowski  wrote:
> Hello,
>
> I have to say sorry for the noise. You were right, after retrying to cleanup 
> my old copies of the working copy it occurred to me that subversion really 
> can clean things up. The problem was that during my initial tests I didn't 
> realize that Eclipse still held the lock when the editor was already closed.
>
> Sorry for that.
>
> Regards,
> Daniel Migowski

Glad you found the issue and resolved it.

My personal approach is "don't use svn:keywords", along with "don't
use svn:eol" The erratic and inconsistent contents of  a working copy
based on various local settings, such as the change author or URL of
the upstream repo, and the extra overhead of "I've committed the file
and the contents will therefore be altered by the commit itself" for
revision based keywords are just begging for this kind of problem to
occur again and again and again.

The consequence of the casual legibility of such keywords is that you
have to spend resources managing keywords, disabling them, avoiding
their accidental use in source code that would have its checksums and
timestamps altered by checkins, etc. It gets very expensive at odd
times, as you just noted. It's frequent use is one of the consequences
of the evolution of Subversion from CVS, and it's one that I've found
more effective to simply reject and avoid altogether.

Probable bug: writes commit messages to read-only trees

[Caitlin Matos]

Hello:

I attempted to add and commit a file to a new repo that I *should* have 
read-write access to. I still can't figure out whether I really have RW or RO 
access, but I think this is irrelevant.

When I committed the file, I received the following message:
  Adding watchfiles/xdg-utils_1.1.0~rc1+git20111210.watch
  Transmitting file data .
  Committed revision 289.

  Warning: post-commit FS processing had error 'attempt to write a readonly 
database'.

When I browsed the repo online, I can see that the history has indeed changed, 
and it references a file that does not exist on the server.

This is very odd behaviour. SVN is writing to the log, THEN attempting to 
upload the file, and if the upload fails, the log persists. 

Suggested behaviour: one of:
  1) determine RO/RW access before writing commit to log; refuse to commit 
if RO
  2) keep as is, but when RO error encountered, undo the commit.

P.S., forgive me if I've gotten some of the lingo wrong. I'm much more familiar 
with git.

svn, version 1.8.9 (r1591380)
   compiled May 21 2014, 03:09:46 on x86_64-pc-linux-gnu

running Debian, tracking testing/jessie
SMP Debian 3.14.4-1 (2014-05-13)

Copy a line from the repo browser

[Havlovick, Ron]

Ya'll:

When the repo browser shows the files, etc within the gui window, is there  a 
way, script or other wise to copy that line shown?
Not the file itself, only the text stating what is in the repo browser. Or a 
print of the window shown?
I have to make a manifest of what is contaminated under that revision number so 
I want to cut and paste the files and their revision numbers to a text file to 
let the other party know.
Any way of doing this.



Ron G. Havlovick
Hardware Design Engineer

Avionics & Electronics Group
Curtiss-Wright
T: 626.851.3100 x2106
rhavlov...@curtisswright.com | 
www.cwc-ae.com


___
This e-mail and any files transmitted with it are proprietary and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have reason to believe that you have received this e-mail in error, please 
notify the sender and destroy this email and any attached files. Please note 
that any views or opinions presented in this e-mail are solely those of the 
author and do not necessarily represent those of the Curtiss-Wright Corporation 
or any of its subsidiaries.  Documents attached hereto may contain technology 
subject to government export regulations. Recipient is solely responsible for 
ensuring that any re-export, transfer or disclosure of this information is in 
accordance with applicable government export regulations.  The recipient should 
check this e-mail and any attachments for the presence of viruses. 
Curtiss-Wright Corporation and its subsidiaries accept no liability for any 
damage caused by any virus transmitted by this e-mail.

Re: Copy a line from the repo browser

[Ryan Schmidt]

On Jul 17, 2014, at 2:22 PM, Havlovick, Ron wrote:

> When the repo browser shows the files, etc within the gui window,

Subversion doesn't have a repo browser or a gui window; you're referring to 
features of TortoiseSVN, which is a separate project with a separate mailing 
list which you should contact for help.