On 2/4/11 9:39 PM, Daniel Andersson wrote:
>
OK, how would I go about then to completely delete the whole versioning history?
One way would be to make sure all your workspaces are commited, export the head
version, then start a new repository and import the directory back to it. Then
delet
On 02/02/2011 09:59 PM, Les Mikesell wrote:
On 2/2/11 2:47 PM, Andy Levy wrote:
On Wed, Feb 2, 2011 at 15:14, Daniel Andersson
wrote:
Hi all,
I deleted a bunch of large files from our repository yesterday that
was not
meant to be stored there. But these are still of course in the SVN
history.
(reordering to remove top-posting)
*From:* ankush chadha
*To:* users@subversion.apache.org
*Sent:* Fri, February 4, 2011 1:47:34 PM
*Subject:* Need help in restoring the svn repository (server side)
Hi All
I am trying to
Found that there is a file named 'current' that stores the HEAD revision. When
I
kicked off svn verify on 133001 it complained that "revisions must not be
greater than the youngest revision" so I knew they stored the HEAD revision
somewhere. Once I updated the value of HEAD, I can see all the r
Hi All
I am trying to recover the repository from a corrupted hard drive. I have very
huge source repository, about 136000 revisions. Luckily I have a 4 month old
backup.
I think I was able to recover the contents of db/revs and db/revprops folder as
it contains 136000 + 1 files each. ( 1 file
* Florian Weimer:
> Switching a working copy to a branch where a locally modified file
> does not exist, and switch back to the original branch (without
> further changes) leaves the working copy in an inconsistent state. It
> is surprisingly difficult to recover from that situation. It seems
>
Switching a working copy to a branch where a locally modified file
does not exist, and switch back to the original branch (without
further changes) leaves the working copy in an inconsistent state. It
is surprisingly difficult to recover from that situation. It seems
that you have to delete the p
Hi,
I took a look at the changes log
(http://svn.apache.org/repos/asf/subversion/tags/1.6.15/CHANGES) and found the
following resolved defect in SVN 1.6.11:
* fixed: theoretical possibility of DB corruption (r926151, -67)
There is however no issue associated with this fix. I am wondering if I
When I merge branch->trunk with directories carrying svn:externals
properties the property values don't merge but report as conflicted
(Note, I usually use tortoiseSVN: their mailinig list sent me here!) Is
this because the property is seen as a single merge element ? Is there
any workaround fo
