Around about 21/09/12 06:26, Sandeep U D typed ...
Actually we were using VSS for source control. Now we are going to migrate
from VSS to SVN.
So like to know the possible options for it.
There are quite a few, none of which I found to be fantastic. You'd have
to google things like
Around about 21/09/12 09:12, Neil Bird typed ...
I may try to blog my process at some point.
Quicker than I thought, the cut'n'paste from MediaWiki into Wordpress
kept all the formatting.
http://fnxweb.com/blog/2012/09/21/migrating-from-visual-sourcesafe-to-subversion/
--
[neil@fnx
I don't know whether this is an artefact of svn itself, TortoiseSvn or a
mixture of the both; the error is being reported from svn's io.c.
A colleague has an IT-locked-down PC where he can't write to the root of
C:\ or D:\. He just tried to do an update (in Tortoise) where there was a
Around about 16/11/11 14:27, Stefan Sperling typed ...
Yes. Any of TMPDIR, TMP, or TEMP should work.
OK, thanks. I have to admit to not having tried those usual suspects (!)
as the problem had been resolved by the time I started digging. I'll try
getting him to set one of those if we see
Around about 10/11/11 17:01, Philip Martin typed ...
It may be as simple as
sqlite .svn/wc.db reindex nodes
sqlite .svn/wc.db reindex pristine
Nope. “Error: database disk image is malformed”.
sqlite3 .svn/wc.db select sql from sqlite_master where name='NODES'
sqlite3 .svn/wc.db select
Having just done a couple of commits (after an update), I did some work
on a file then went to commit again (no 2nd. update) and TortoiseSVN
reported no changes.
A command line 'svn status .' is giving me:
svn: E200030: database disk image is malformed
svn: E200030: database disk image
Around about 10/11/11 13:21, Philip Martin typed ...
pragma integrity_check
I'd done that, but it doesn't mean anything to me!
*** in database main ***
On tree page 40898 cell 60: 2nd reference to page 325
On tree page 40898 cell 60: Child page depth differs
On tree page 40898 cell 61:
I have a local file in a WC. I have svn-deleted the local file and
re-added it as a file external from elsewhere (to the same WC location using
the immediate parent's svn:externals).
However, on update I now get an error along the lines of:
Updating 'tools':
Fetching external item
Around about 09/11/11 11:39, Neil Bird typed ...
Annoyingly I tried to re-create this with a dummy/example pair of repos, and
it all worked swimmingly.
Actually a typo. meant it wasn't reproducing the situation.
The attached script mostly reproduces the problem. I've got my repo
Around about 09/11/11 14:27, Stefan Podskubka typed ...
Isn't this the expected behaviour regarding the current state of the
svn:externals implementation?
Gah, you are, indeed, correct, and I'd even *read* that before, but
forgotten!
Thanks (to you Philip) for correcting my numptiness!
I can't find any reference online to this error code. I am trying to do
a command line 'svn cp' of one file to a new name in the same directory:
$ svn cp 3.14.7.html 3.14.8.html
svn: E200033: database is locked, executing statement 'RELEASE s0'
This with a freshly upgraded (from
Around about 31/10/11 16:21, michael.ru...@t-systems.com typed ...
2. Open the browser window URL to merge from: - ...
You need to enter a URL, otherwise the ... will not open any window.
If you enter the old ^/trunk it switches back to the current root, as the window opens
with HEAD revision.
Around about 01/11/11 12:12, Daniel Shahaf typed ...
database is locked is the error SQLite would give when it tries to write to a
database (.svn/wc.db) on which some other process already has a write-lock. The SQLite
documentation:
... SQLite relies on POSIX advisory locks. Do those locks
A colleague just posed this question to me: if one does a merge from
trunk to one's local branch to get up to date, and one of the items merged
is an update to svn:externals, should svn not automatically perform an
update on those externals?
At the moment, one has to do do a 'svn
Around about 01/11/11 13:22, Daniel Shahaf typed ...
... However you mentioned CIFS-mounted working
copies, in which case the issue will be concurrent access not to the
repository but to the working copy.
Yeah, I said repo., but I meant WC! And I meant that I don't do more
than one thing
Whilst suffering a subversion server outage, it's made me wonder: we
currently produce nightly backups of our repos via 'hotcopy' from the
server's local drive to a network store.
If the server were to die, would I be able to take those copies and place
them under a server on a new box
Around about 26/10/11 12:28, Stefan Sperling typed ...
With FSFS repositories, yes, it will work if you copy the files
onto the new system from the network store (it might not if you try
to mount a disk from the old system on the new system directly, then
it depends on OS filesystem support and
Around about 06/10/11 10:07, Jon Hardcastle typed ...
I have an oddity I have never seen before. I have a log entry when viewed
from tortoise that has no author, actions, message and says (no date) for
the date and time.
I saw that yesterday: for me, it was a permissions thing.
Under
Around about 29/09/11 14:20, vishwajeet singh typed ...
You can checkout svnmanager http://svnmanager.org/
Around about 29/09/11 14:23, Mark Phippard typed ...
Subversion Edge supports this. It simply loads the authz file into a
text field in your browser though (no fancy high-click UI).
Can anyone recommend a relatively light-weight AuthzSVNAccessFile editor?
I just tried svn-access-manager but it's fundamentally broken in a few
places I gave up trying to get it to work.
Really, all I want is for those people in charge of a repo. to be able to
edit that repo's (but
Around about 01/08/11 05:02, Andy Canfield typed ...
I am user andy. I can point my browser to http://SERVER/svn/subdoc; or even
http://SERVER/svn/fred3; with no problem, but not http://SERVER/svn; --
403 Forbidden. I think I've done everything that the documentation says I
should do, but it
Around about 26/07/11 15:35, Phil Pinkerton typed ...
Questions : Switch vs relocate ?
Effects of load into a new Subversion version ?
That all sounds fine¹; you will need 'svn switch --relocate new-url'
to maintain each existing working copy, as you surmised.
The
Around about 03/06/11 23:20, Nico Kadel-Garcia typed ...
Faster than than it was for .6.16 or earlier with the Linux client? Good
Yes, tested the new TSVN this morning on our standard codebase. A full
checkout last week on the old TSVN took just shy of 15 mins. (2-3 of its
dirs. have
Around about 03/06/11 03:46, Nico Kadel-Garcia typed ...
And, apparently, the long-standing issue for clients with NTFS
filesystems sytems, issue #3719. I'm very much looking forward to
testing against a CIFS share, which was taking easily 10 times as long
as checkouts on NFS shares.
The
Around about 27/04/11 05:09, Hyrum K. Wright typed ...
The bugfix has been merged to the 1.6.x branch, so that's the one to
be testing now:
http://svn.apache.org/repos/asf/subversion/branches/1.6.x/
FWIW, 1.6.x now works for me on this issue (I had previously proven the
1.6.x-issue371
Around about 08/02/11 09:03, Daniel Shahaf typed ...
Thanks. However, to clarify, I'm not specifically interested in the
give us N revisions form; I'm just interested in seeing a coherent
patch at the end, and wanted to ensure you haven't forgotten that in
depth of coding.
Good luck / and
Around about 02/02/11 15:26, Stefan Sperling typed ...
Please submit a patch against the 1.6.x branch. I will handle it.
Will do, thanks.
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit
Around about 01/02/11 18:00, Mark Phippard typed ...
I created a folder with 5001 files in it ... maybe that is not enough?
I think the issue is to do with properties, so you'd have to make sure
all those files have props. (we use autoprops for
mime-type/eol-style/header-expansion).
Around about 27/01/11 12:51, Nico Kadel-Garcia typed ...
Are you *normally* out to a CIFS shared location, or to local NTFS
disk?
Not ... as such. No, this was particularly to test the client code/OS to
try to pin things down for this issue.
--
[neil@fnx ~]# rm -f .signature
[neil@fnx
Around about 28/01/11 04:32, Daniel Shahaf typed ...
(I don't recall why the fixes on trunk weren't backported, but I imagine
the threads linked from this thread say why.)
The threads (that I've see) all peter out, with the last event being some
saying a colleague was about to compile 1.6
Around about 01/02/11 15:36, Neil Bird typed ...
I've had no response from the email I sent him privately, so I may try that
myself, and maybe then raise a ticket (or whatever system they use) to ask
for the backport if it works.
My bad, I just found Thunderbird has mis-threaded his reply
Around about 27/01/11 01:40, Johan Corveleyn typed ...
http://svn.haxx.se/dev/archive-2010-04/0180.shtml
Maybe someone else can comment more on this, and why it wasn't
backported to 1.6 (or is it?).
Excellent, yes, that would seem to be it. I did notice the huge number
of counted .tmp
Around about 27/01/11 12:46, Nico Kadel-Garcia typed ...
I've not seen this, but I'm using Linux, not Solaris, as a server. Are
you using the Sun provided Apache? Or your own? And is it the built-in
mod_dav_svn module, or are you doing something else? What's in your
Apache logs?
No, I've
I should probably go to the Apache-specific site for this, but I thought
I'd ask here in case anyone else has seen the like.
We have Apache running as a Subversion server on a Solaris 10 box. It's
all working a treat.
Now, we have the server explicitly only talking SVN over https,
We have a graphics-oriented code-base that's auto-generated and has 5000
source files in one directory. While I can check this out OK on Linux,
we're seeing an unusable slow-down on Windows XP (NTFS), both using Tortoise
directly, and as a test on Linux with the Windows drive mapped over
Around about 26/01/11 14:41, Campbell Allan typed ...
If the code is auto generated would it be possible to generate it for each
build?
Interesting question; I shall have to ask it. I *think*, in actual
fact, that it was *originally* generated, but has since been tweaked
manually or with
Around about 26/01/11 14:43, Andy Levy typed ...
It's known and oft-lamented. NTFS just doesn't handle this scenario
well - it's probably one of the reasons FSFS sharding was introduced
(I'm speculating a bit here).
This is stuff that's currently in SourceSafe, which doesn't exhibit any
Around about 26/01/11 15:24, Stefan Sperling typed ...
Don't run virus scanners on working copies.
If you want to check for viruses in the repository, use a designated
working copy and trigger a scan of changed files from the post-commit hook.
The virus scanner excludes this particular
Around about 26/01/11 15:30, Echlin, Jamie typed ...
Perhaps your Master File Table is fragmented... In which case a defrag
might help.
We see exactly the same problem on two diff. Windows PCs, but I'll give
ImDisk a bash in the morning for the sake of experimentation.
And I recently
A colleague new to Subversion has a part of a project spread across a
number of sibling directories. He had been making some significant changes
and didn't want to “risk” doing a ‘svn update’ on the top level directory,
instead manually doing updates on the siblings of the main directory
Around about 04/11/10 10:16, Giulio Troccoli typed ...
Maybe you could try the ls command with a URL
Well, yes, if I 'ls' the repo I'm going to see what should be there.
What I wanted to know was if there was any local indication; something
that would show me while I was offline.
--
Around about 30/09/10 01:21, Tech Geek typed ...
1. Repositories created on shared network drive with 1.6.12 subversion
engine (svnadmin) or 1.6.10 TSVN, will not commit through TSVN or even
through a Linux svn client.
Not that I can help, but I wanted to clarify: you have a repo on a
Is there any way possible (aside from write a script to generate modified
files) to update, checkout or otherwise fetch files from svn *without*
having it honour the svn:keywords property (and without permanently removing
said property)?
This is for the purposes of doing some
Around about 20/07/10 04:10, Kitching, Simon typed ...
Ah well, as it appears that nobody here knows the answer I'll just have
to do it the ugly way: try to get the svn repo administrator to install
some hooks to prevent this occurring in future, and then install cygwin
on somebody's windows PC
I've been using svn on and off for a while, and have recently started
using it at work after finally managing to migrate from SourceSafe.
We have what might appear to be a slightly peculiar code hierarchy, and
it's true that it was largely begat from using multiple SourceSafe
databases,
45 matches
Mail list logo
