Re: cvs2svn failing on "non-CVS" files
On 09/13/2012 12:30 AM, Nico Kadel-Garcia wrote: > I'm helping upgrade a 12 year old CVS repository to use modern source > control, and have run into a bit of a surprise. Running either cvs2svn > or cvs2git, I'm finding a couple of old CVS files that were hand > edited, 6 hears, and cause cvs2svn to fail with this kind of error. > > > /data/cvs/tusk/ocw/tmpl/Attic/header,v > Processed 5345 files > Pass 1 complete. > === > Error summary: > ERROR: '/var/www/cvs/module/badfile,v' is not a valid ,v file > > This is with cvs2svn 2.3.0, Subversion 1.6.12 on Ubuntu or Subversion > 1.6.11 on RHEL. I've also tested with Subvesion 1.7.4 on RHEL, same > problem. My problem is that the CVS files check out OK with plain CVS, > and my clients really want to keep the history intact in their > migration. > > Has anyone had fun and experience with CVS files that work in CVS, but > break cvs2svn? Are there any particular pointers? Any guidelines on > repairing such mangled files? Often CVS can check recent revisions out of a repository file even if it is corrupt, because in that case CVS doesn't need to read the whole file. But it is likely that CVS would also have problems if you tried to check out older revisions. For example, for a relatively thorough test try using CVS to check out revision 1.1 and the tips of all branches for the affected files. It is probably possible for somebody who knows the RCS/CVS file format to fix these files by hand and salvage some or all of the file's history. If you need assistance, please contact me off-list. Michael (the cvs2svn maintainer) -- Michael Haggerty mhag...@alum.mit.edu
Limit general read-operations to svn-repo
Dear Users, We're having around 40 repositories. I'm trying to limit write access to a specific group per repository and all read access to a group. How can i achieve this? I was able to limit the write operations with: Require ldap-group CN=svn-repo-install-read But how can i set a general Limit for all repos below /svn/ for read? ... is not working: Require ldap-group CN=SVN_user I would like to have that users prompted for credentials when they try to read from repos below /svn and the credentials are checked if the user is part of SVN_user. Thank you in advance Stefan
Re: Problem with merging
On 12/09/12 18:39, John Maher wrote: Hello [CUT] Can you please stop reusing an already existing thread and instead start a new one for a new question? Thanks John Thanks Giulio
RE: cvs2svn failing on "non-CVS" files
> /data/cvs/tusk/ocw/tmpl/Attic/header,v > Processed 5345 files > Pass 1 complete. > == > = > Error summary: > ERROR: '/var/www/cvs/module/badfile,v' is not a valid ,v file > > Has anyone had fun and experience with CVS files that work in CVS, but > break cvs2svn? Are there any particular pointers? Any guidelines on > repairing such mangled files? We have had similar errors when we changed. The only solution I had was to remove these files from the CVS repo and finally re-add them in the svn repo. Of course this works only if there are only a few files (it was 6 in our case) The actual cause in our case was: CVSNT (!) has saved these files (they were all binary) with a '0' somewhere in the file what the converter didn't like... Best regards Andreas -- Andreas Tscharner -- "Intruder on level one. All Aliens please proceed to level one." -- Call in "Alien: Resurrection"
RE: Problem with merging
Thanks Stefan. I did read most of the links. I didn't know about the FAQ, thanks. Your statement was key: "Note that the "tree" being talked about there is not an individual branch, but all nodes in the repository, including the /trunk directory and the /branches/feature directory." Basically in the book in that section tree means repository. But you cleared it up and the FAQ helped because the fact calls it the repository tree. How hard is it to change the book? I know what it means now, but the next person may get confused. I would bet that someone will eventually get confused. If it said "repository tree" like the FAQ I would bet it helps. John
RE: Problem with merging
Thanks Thorsten. While its true that I didn't technically lose code, it was probably in there somewhere. The loss was discovered weeks later and we have a lot of code. It would take days going over everything then we would have to *hope* we got everything. Some things would let us know if we missed them, others things may not. We could go days or weeks before we noticed we were losing data. Since we were a few weeks away from the next release I decided to put off updating production. Basically it would cost too much to possibly not get all the code sprinkled with a slim chance of data loss. So from a business perspective, the code was lost. In reality we should've had code control a long time ago. I only got here a few years ago. And when I first got here I met extreme resistance about incorporating something like subversion. I finally got the green light, quite possibly because they didn't have to spend any money. Now I must learn to use it. :) Revisions are global is what I needed to know, thanks. John -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Wednesday, September 12, 2012 2:39 PM To: users@subversion.apache.org Subject: Re: Problem with merging Guten Tag John Maher, am Mittwoch, 12. September 2012 um 19:39 schrieben Sie: > I started using subversion a while back and doing a merge I lost a bunch > of source code which prohibited me from updating production for weeks. Unless you didn't commit, you can't loose source code, that's what version control is all about. Even if you didn't commit Subversion would always try everything to preserve your current modifications, which may result in the conflicts you describe later. The easiest way to never ever loose anything it always commit before doing any changes to your working copy like merges and whatever goes wrong after a commit can be restored. > I now have a stable code base and wish to use subversion so I tried to > follow chapter 4, branching and merging. It failed. If you mean your later mentioned conflicts with "failed", this isn't exactly true, as a conflict is a normal operation and the merge may succeed. Conflicts only mean that there are changes which Subversion can't merge automatically safely and the user needs to do something to merge the changes. This is not the same as an error during the merge or else. > 1) I was on revision 4. I then branced it, made a change and it > jumped to revision 7. Why? Does the revision apply to all folders > under a repository? Yes, revisions are global, that's one of the fundamental concepts of Subversion and is normally considered as a major benefit over previous centralized version control like CVS. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Problem with merging
Guten Tag John Maher, am Donnerstag, 13. September 2012 um 15:35 schrieben Sie: > In reality we should've had code control a long time ago. I only > got here a few years ago. And when I first got here I met extreme > resistance about incorporating something like subversion. I finally > got the green light, quite possibly because they didn't have to > spend any money. Now I must learn to use it. :) Prepare yourself for the day you loose a repository. I had a lot of fun explaining my manager why I'm working two days on restoring things from our corrupted NTFS file system and why it's worth the time to not just drop version control. :-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Problem with merging
Can you tell me what that means? I had a question on merging so I sent it to the mailing list. Are you saying I'm not supposed to do that? If not then can you explain the procedure? John -Original Message- From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk] Sent: Thursday, September 13, 2012 4:56 AM To: John Maher Cc: users@subversion.apache.org Subject: Re: Problem with merging On 12/09/12 18:39, John Maher wrote: > Hello [CUT] Can you please stop reusing an already existing thread and instead start a new one for a new question? > Thanks > John Thanks Giulio
Re: Problem with merging
On 13/09/12 15:15, John Maher wrote: Can you tell me what that means? I had a question on merging so I sent it to the mailing list. Are you saying I'm not supposed to do that? If not then can you explain the procedure? You are hijacking someone else's email. Presumably you have clicked on Reply or ReplyAll to a previous email and changed the subject and text. Unfortunately this means that your email is going in the same thread as the one you replied to, which is not related to your problem. When asking a new question simply send a new email, don't reply to one. I hope I was clearer now. Giulio
RE: Problem with merging
Yes that is what I did. Now that I know that causes problems with the subversion mailing list I won't do it again. John -Original Message- From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk] Sent: Thursday, September 13, 2012 10:25 AM To: John Maher Cc: users@subversion.apache.org Subject: Re: Problem with merging On 13/09/12 15:15, John Maher wrote: > Can you tell me what that means? I had a question on merging so I sent > it to the mailing list. Are you saying I'm not supposed to do that? If > not then can you explain the procedure? You are hijacking someone else's email. Presumably you have clicked on Reply or ReplyAll to a previous email and changed the subject and text. Unfortunately this means that your email is going in the same thread as the one you replied to, which is not related to your problem. When asking a new question simply send a new email, don't reply to one. I hope I was clearer now. Giulio
Re: Problem with merging
On 13/09/12 15:26, John Maher wrote: Yes that is what I did. Now that I know that causes problems with the subversion mailing list I won't do it again. John Thank you Giulio
Re: Problem with merging
Guten Tag John Maher, am Donnerstag, 13. September 2012 um 16:26 schrieben Sie: > Yes that is what I did. Now that I know that causes problems with the > subversion mailing list I won't do it again. It causes problems on nearly every mailing list as they each work similar. The first mail you sent has a "References" header referring the mail you answered to and changed the subject, new mails don't. That's what most mail clients etc. use to identify and build threads. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Problem with merging
On Sep 13, 2012, at 08:23, John Maher wrote: > How hard is it to change the book? I know what it means now, but the > next person may get confused. I would bet that someone will eventually > get confused. If it said "repository tree" like the FAQ I would bet it > helps. Book feedback should be sent to the book's authors. Go to: http://svnbook.org/ and scroll down to the "Feedback/Contributing" heading.
