Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Michael Haggerty
Is this you? Claim Profile »
3 months ago
in Order of Operations on Adam @ Heroku
This is terrible advice.
* Security is a result of the initial design and continual conscientiousness during the implementation, not of retroactive auditing and hardening.
* Elegance is key to writing working and secure code. It is not a varnish that is slopped on afterwards.
* Once your manager / client / whatever sees the code working, they won't allocate resources for steps 2 - 4.
Except for the most trivial or speculative projects, your steps 1 and 2 and 4 have to be carried out in parallel as the functionality is incrementally added. I agree, though, that 3 can be delayed.
* Security is a result of the initial design and continual conscientiousness during the implementation, not of retroactive auditing and hardening.
* Elegance is key to writing working and secure code. It is not a varnish that is slopped on afterwards.
* Once your manager / client / whatever sees the code working, they won't allocate resources for steps 2 - 4.
Except for the most trivial or speculative projects, your steps 1 and 2 and 4 have to be carried out in parallel as the functionality is incrementally added. I agree, though, that 3 can be delayed.
2 years ago
in Converting a CVS repository to SVN on CommaVee
Your comments got me thinking about a resumable pass1. It wouldn't be terribly hard to implement. (No promises, though :-) )
Regarding "depth" problems: I think a far more likely explanation is that a "deep" repository is likely to be an old one that has accumulated repository corruption over the years. But consider submitting your unprocessable *,v files to the user mailing list if you think they are not corrupt.
Granted, it would be nice if we could provide a more specific error message in the case of a corrupt *,v file. I don't think that the parser that we use provides more information, but I'll double-check.
For further discussion, the users@cvs2svn mailing list would be more appropriate so that other members of the cvs2svn community can participate.
Regarding "depth" problems: I think a far more likely explanation is that a "deep" repository is likely to be an old one that has accumulated repository corruption over the years. But consider submitting your unprocessable *,v files to the user mailing list if you think they are not corrupt.
Granted, it would be nice if we could provide a more specific error message in the case of a corrupt *,v file. I don't think that the parser that we use provides more information, but I'll double-check.
For further discussion, the users@cvs2svn mailing list would be more appropriate so that other members of the cvs2svn community can participate.
2 years ago
in Converting a CVS repository to SVN on CommaVee
I am currently the main developer/maintainer of cvs2svn. I read your article with interest, and would like to discuss some of the points that you made.
I do not know of any problems in cvs2svn that are caused by deep repositories or repositories with lots of branches. If you have found some, please let us know.
You claim that cvs2svn cannot be restarted. This is partly correct. The individual passes of cvs2svn are self-contained and can be re-run. Thus if there is a problem in pass4, you don't have to restart the conversion at pass1. This can be a big benefit, particularly when dealing with tag/branch names that were used inconsistently.
However, you are correct that pass1, in which the data are parsed out of CVS, cannot be restarted if there is an error.
We try to give reasonable error messages (and sometimes workarounds) for the kinds of repository corruption that have been reported to us
frequently. If you have found other common failure modes, please report them to our mailing list and we will look at them.
Regarding symbol names with appended carriage returns:
I've never seen this problem; thanks for pointing it out. If you would send an email to the users mailing list including a snippet of a CVS repository that shows this problem, I'd be happy to look at it. If you have any suggestions for how you think cvs2svn should work around this problem, please let us know.
Regarding the --retain-conflicting-attic-files option:
This option has been added to the trunk version of cvs2svn (and works, as far as I know), and that is why it is included in the online documentation. But the latest official release, 1.5.1, does not yet include this feature. I understand that this discrepancy can lead to confusion.
I do not know of any problems in cvs2svn that are caused by deep repositories or repositories with lots of branches. If you have found some, please let us know.
You claim that cvs2svn cannot be restarted. This is partly correct. The individual passes of cvs2svn are self-contained and can be re-run. Thus if there is a problem in pass4, you don't have to restart the conversion at pass1. This can be a big benefit, particularly when dealing with tag/branch names that were used inconsistently.
However, you are correct that pass1, in which the data are parsed out of CVS, cannot be restarted if there is an error.
We try to give reasonable error messages (and sometimes workarounds) for the kinds of repository corruption that have been reported to us
frequently. If you have found other common failure modes, please report them to our mailing list and we will look at them.
Regarding symbol names with appended carriage returns:
I've never seen this problem; thanks for pointing it out. If you would send an email to the users mailing list including a snippet of a CVS repository that shows this problem, I'd be happy to look at it. If you have any suggestions for how you think cvs2svn should work around this problem, please let us know.
Regarding the --retain-conflicting-attic-files option:
This option has been added to the trunk version of cvs2svn (and works, as far as I know), and that is why it is included in the online documentation. But the latest official release, 1.5.1, does not yet include this feature. I understand that this discrepancy can lead to confusion.
