Re: Can't get exclusive lock on NAS repo lock files after upgrading to Mac OS X High Sierra
On Jan 20, 2018, at 4:03 PM, Julius Smith wrote: > > I was cruising along great with my subversion repos on my NAS and my > working copies on Mac OS X Sierra, but after upgrading to High Sierra > I see this whenever I try to check something in: > >> svn ci -m 'update' > svn: E45: Commit failed (details follow): > svn: E45: Can't get exclusive lock on file > '/Volumes/Repos/SubversionRepos/svnr/scriptssvn/db/txn-current-lock': > Operation not supported > > I have tried mounting the NAS using every filesystem format supported > (I have a QNAP Model TS-453 Pro), and the problem persists. Is your svn server process running on a different machine than the repo storage? Did you try installing your svn server process on the NAS? I am not familiar with your NAS but a quick google search brought this up: http://blog.sebastian-martens.de/technology/install-svn-on-qnap/
RE: Exe files corrupted in SVN after import from CVS
On Sat, 20 Jan 2018 13:19:26 -0500, Nico Kadel-Garcia wrote: >I suspect you can simplify the whole situation a great deal by moving >at least this project to its own Subversion repository. You should be >able to to at least test and debug ideas by doing a cvs2svn of just >that project and trying out ideas. And you can import that into a >local working Subversion repository, rather than touching the primary >repository at all. > I am leaning toward a completely different approach now concerning the PC (Windows) software development repository: 1) I leave the CVS server running but I confgure it as read-only. This makes it possible for people to export older stuff if needed. 2) I export trunk of the projects that need to be worked on from CVS 3) I start over with an empty SVN repository and import the exported projects into SVN, so they are the first revision there. This way svn will be a smaller size and the content should be OK since the projects are not *converted* from CVS but imported as regular normal projects. We also use CVS (and now SVN) as a store for drawings and printed circuit board projects (PCB). We are using an engineering repository for these but I found that the converted structure is less than optimal when using SVN because of the tags and branches directories. In CVS we have a subdirectory for drawing sources (DWG) and another for PDF versions (PDF) and also a subdirectory for the boards (PCB). Like this: REPO |-DWG |-PDF |-PCB |-and a few more that do not have sub-containers These subdirectories were treated as "projects" during conversion, which has led to a problem since there is now only one tags, trunk and brances dir for ALL of the drawings and another set for all PCB:s etc. So when I looked at the converted repository there is a total mess in the tags directory because we have used tag names like Rev_A, Rev_B etc for almost all PCB:s and now these are merged and contains an assortment of different unrelated projects... In CVS the tag was a property of any given *file* but in SVN it is on a whole directory, or really not even this... It is just a copy of the directory with a different name, not a property of the directory... Seems like I have to scrap the conversion also for Engineering and do something else, but what? Separate repositories for drawings, PDF releases and PCB:s maybe? Regards, Bo B (PS: Had to send this as regular email since the posting I made through Gmane seems to have disappeared. DS)
Re: Exe files corrupted in SVN after import from CVS
On Sat, 20 Jan 2018 13:19:26 -0500, Nico Kadel-Garcia wrote: >I suspect you can simplify the whole situation a great deal by moving >at least this project to its own Subversion repository. You should be >able to to at least test and debug ideas by doing a cvs2svn of just >that project and trying out ideas. And you can import that into a >local working Subversion repository, rather than touching the primary >repository at all. > I am leaning toward a completely different approach now concerning the PC (Windows) software development repository: 1) I leave the CVS server running but I confgure it as read-only. This makes it possible for people to export older stuff if needed. 2) I export trunk of the projects that need to be worked on from CVS 3) I start over with an empty SVN repository and import the exported projects into SVN, so they are the first revision there. This way svn will be a smaller size and the content should be OK since the projects are not *converted* from CVS but imported as regular normal projects. We also use CVS (and now SVN) as a store for drawings and printed circuit board projects (PCB). We are using an engineering repository for these but I found that the converted structure is less than optimal when using SVN because of the tags and branches directories. In CVS we have a subdirectory for drawing sources (DWG) and another for PDF versions (PDF) and also a subdirectory for the boards (PCB). Like this: REPO |-DWG |-PDF |-PCB |-and a few more that do not have sub-containers These subdirectories were treated as "projects" during conversion, which has led to a problem since there is now only one tags, trunk and brances dir for ALL of the drawings and another set for all PCB:s etc. So when I looked at the converted repository there is a total mess in the tags directory because we have used tag names like Rev_A, Rev_B etc for almost all PCB:s and now these are merged and contains an assortment of different unrelated projects... In CVS the tag was a property of any given *file* but in SVN it is on a whole directory, or really not even this... It is just a copy of the directory with a different name, not a property of the directory... Seems like I have to scrap the conversion also for Engineering and do something else, but what? Separate repositories for drawings, PDF releases and PCB:s maybe? -- Bo Berglund Developer in Sweden
Re: Exe files corrupted in SVN after import from CVS
On Jan 20, 2018, at 10:25, Bo Berglund wrote: > I have found that there is a problem in our SVN repository, which was > converted from CVS using cvs2svn 2.5.0. > > It concerns two exe files which are corrupted when I check out or > export them. The trunk files have been expanded by 905 bytes or shrunk > by 119 bytes in the two cases. Both are in the same project. They have > 82 and 67 commits into them respectively. Did you or your conversion process set the svn:eol-style property on these files? If so, that's why they got corrupted; you mustn't set that property on binary files.
Re: Exe files corrupted in SVN after import from CVS
On Sun, 21 Jan 2018 22:23:21 -0600, Ryan Schmidt
wrote:
>
>On Jan 20, 2018, at 10:25, Bo Berglund wrote:
>
>> I have found that there is a problem in our SVN repository, which was
>> converted from CVS using cvs2svn 2.5.0.
>>
>> It concerns two exe files which are corrupted when I check out or
>> export them. The trunk files have been expanded by 905 bytes or shrunk
>> by 119 bytes in the two cases. Both are in the same project. They have
>> 82 and 67 commits into them respectively.
>
>Did you or your conversion process set the svn:eol-style property on
>these files? If so, that's why they got corrupted; you mustn't set
>that property on binary files.
Well, most of the exe files got converted without this problem, so it
could not really be a global mistake in the way file properties are
set.
This is how I configured individual conversions, the remaining options
file content stayed the same for all repos:
outdumpfile='pc-dump'
inputreponame='PC'
This is my options settings for the cvs2svn conversion regarding
properties, mostly defaults in the options file example from cvs2svn):
ctx.file_property_setters.extend([
CVSBinaryFileEOLStyleSetter(),
CVSBinaryFileDefaultMimeTypeSetter(),
DefaultEOLStyleSetter(None),
SVNBinaryFileKeywordsPropertySetter(),
KeywordsPropertySetter(config.SVN_KEYWORDS_VALUE),
ExecutablePropertySetter(),
DescriptionPropertySetter(propname='cvs:description'),
SVNKeywordHandlingPropertySetter(),
SVNEOLFixPropertySetter(),
])
ctx.revision_property_setters.extend([
])
and this is how the CVS top level directories were treated as
"projects" during conversion:
# 1)List all projects automatically
import os
cvs_repo_main_dir = '/home/bosse/CVSREPOS/' + inputreponame
projects = os.listdir(cvs_repo_main_dir)
# 2) Probably you don't want to convert CVSROOT:
projects.remove('CVSROOT')
# 3) Now loop projects and add to conversion list
for project in projects:
run_options.add_project(
cvs_repo_main_dir + '/' + project,
trunk_path=(project + '/trunk'),
branches_path=(project + '/branches'),
tags_path=(project + '/tags'),
symbol_strategy_rules=global_symbol_strategy_rules,
)
So, the options file stayed the same for all 8 CVS repositories except
regarding the definition of the repo to convert and the output dump
file name. Also I have not (yet) found any more corrupted exe files
than these two that were compiled using Borland C++Builder and had CVS
revision files with a huge size of 487Mb and 367Mb respectively.
Therefore I suspect that either the RCS file size itself caused a
problem for cvs2svn, or there is some kind of internal exe file byte
pattern in such files that triggers an action in cvs2svn which causes
the file corruption...
The Ubuntu 16.04 Server (virtual machine) on which I ran the
conversion has a RAM allotment of 2 GB, maybe this is too little when
dealing with these huge files?
Checking out these files from CVS, even very old revisions from say
2006, still works successfully.
--
Bo Berglund
Developer in Sweden
