SVN repository online! All XML, ROMs, tools, spreadsheets go here!
#17
Some good points SoCal. To answer a few:
- how many EvoM users are technical enough / want to bother with a version control system?
Most people won't want to use the full feature-set of SVN. But, at the very least, people should be able to download content from the repository. And developers can point people to this one central location rather than to a thread or a post in a thread.
--- Note 1: WYSIWYG wiki is easier for non-technical folks to use
--- Note 2: SVN still useful for non-technical users as central repository, with anon (evom, evom) access
- does not obviate need for Wiki or other mechanism to explain new ROMS, features etc. (yeah, you can get around it by e.g. adding readme file to relevant ROM dirs, but not as user-friendly)
Yea, I would not expect SVN to take the place of an efficient Wiki. The two can compliment each other nicely, with documentation & how-to's on the Wiki and software stored and managed in the repository.
- steps being taken to backup the SVN repository?
Weekly full backups from my server in Boston, MA to a dedicated datacenter in Columbus, OH.
- open to abuse by users storing objectionable material, attempting to delete files, general hacking etc.
True. I think this is the kind of thing that we eventually convert to a hard account-based tool as opposed to anonymous access. But for the initial stages, it just makes it easier to allow open access.
- how many EvoM users are technical enough / want to bother with a version control system?
Most people won't want to use the full feature-set of SVN. But, at the very least, people should be able to download content from the repository. And developers can point people to this one central location rather than to a thread or a post in a thread.
--- Note 1: WYSIWYG wiki is easier for non-technical folks to use
--- Note 2: SVN still useful for non-technical users as central repository, with anon (evom, evom) access
- does not obviate need for Wiki or other mechanism to explain new ROMS, features etc. (yeah, you can get around it by e.g. adding readme file to relevant ROM dirs, but not as user-friendly)
Yea, I would not expect SVN to take the place of an efficient Wiki. The two can compliment each other nicely, with documentation & how-to's on the Wiki and software stored and managed in the repository.
- steps being taken to backup the SVN repository?
Weekly full backups from my server in Boston, MA to a dedicated datacenter in Columbus, OH.
- open to abuse by users storing objectionable material, attempting to delete files, general hacking etc.
True. I think this is the kind of thing that we eventually convert to a hard account-based tool as opposed to anonymous access. But for the initial stages, it just makes it easier to allow open access.
#18
Evolved Member
iTrader: (2)
FSMs, CAPS, and EcuFlash installers (the latter probably isn't a problem, although his licensing has always been ambiguous)?
Glad I'm not the one hosting the repo. That being said, I've added my collection of Renesas platform documentation as well.
(And FYI to whoever uploaded it: CAPS isn't the most recent software from Mitsubishi for parts lookup purposes; what you really want is ASA, or Mitsubishi "Aftersales Support Application". It's dramatically better.)
Glad I'm not the one hosting the repo. That being said, I've added my collection of Renesas platform documentation as well.
(And FYI to whoever uploaded it: CAPS isn't the most recent software from Mitsubishi for parts lookup purposes; what you really want is ASA, or Mitsubishi "Aftersales Support Application". It's dramatically better.)
#19
I think it's confusing to have 2 dirs of the same name, one containing the tool and the other containing the XML defs for the tool. Suggest moving & renaming /ecuflash to /tools/ecuflash/xml, since /ecuflash actually contains XML defs for ecuflash, not ecuflash itself ... likewise for evoscan.
#20
I think it's confusing to have 2 dirs of the same name, one containing the tool and the other containing the XML defs for the tool. Suggest moving & renaming /ecuflash to /tools/ecuflash/xml, since /ecuflash actually contains XML defs for ecuflash, not ecuflash itself ... likewise for evoscan.
#22
Evolved Member
iTrader: (39)
FSMs, CAPS, and EcuFlash installers (the latter probably isn't a problem, although his licensing has always been ambiguous)?
Glad I'm not the one hosting the repo. That being said, I've added my collection of Renesas platform documentation as well.
(And FYI to whoever uploaded it: CAPS isn't the most recent software from Mitsubishi for parts lookup purposes; what you really want is ASA, or Mitsubishi "Aftersales Support Application". It's dramatically better.)
Glad I'm not the one hosting the repo. That being said, I've added my collection of Renesas platform documentation as well.
(And FYI to whoever uploaded it: CAPS isn't the most recent software from Mitsubishi for parts lookup purposes; what you really want is ASA, or Mitsubishi "Aftersales Support Application". It's dramatically better.)
#23
Evolved Member
iTrader: (2)
Not that I'd encourage the trafficking of such a thing, but...well, it's HUGE. The US version is one ISO, and it's two more ISOs each for Japan, Europe, and Asia. (7 640MB ISOs total)
Probably not really appropriate for a version control system. Perhaps elsewhere on the Internet, you might find something.
Probably not really appropriate for a version control system. Perhaps elsewhere on the Internet, you might find something.
#26
Evolved Member
iTrader: (4)
Outstanding!
If there is one thing to say about the malicious people who would kill an open port access to ROM's etc, it would be because of the access control. How many hacks and virus are on linux open port, and then ask the same question of windows.
My thinking is the number of users that visit this. Leaving it open gets rid of the "security" attitude behind everything that is secure. It's a sharing folder, if you restrict people, you will lose people. You password protect, etc, you make it something worth hacking, most hackers want the challenge. Leave it open, just have the Moderators patrol what gets added. Say I submit something today, hold what I submit for a 72 hour period. That way people can look over it, such as the guru's who understand if it is a good table, address, or scaling.
I am deffinitly in support of open, and read access. Write access is what I would secure.
Just my 2 cents. Carry on, and thank you for getting it setup.
If there is one thing to say about the malicious people who would kill an open port access to ROM's etc, it would be because of the access control. How many hacks and virus are on linux open port, and then ask the same question of windows.
My thinking is the number of users that visit this. Leaving it open gets rid of the "security" attitude behind everything that is secure. It's a sharing folder, if you restrict people, you will lose people. You password protect, etc, you make it something worth hacking, most hackers want the challenge. Leave it open, just have the Moderators patrol what gets added. Say I submit something today, hold what I submit for a 72 hour period. That way people can look over it, such as the guru's who understand if it is a good table, address, or scaling.
I am deffinitly in support of open, and read access. Write access is what I would secure.
Just my 2 cents. Carry on, and thank you for getting it setup.
#28
Evolved Member
iTrader: (22)
Outstanding!
If there is one thing to say about the malicious people who would kill an open port access to ROM's etc, it would be because of the access control. How many hacks and virus are on linux open port, and then ask the same question of windows.
My thinking is the number of users that visit this. Leaving it open gets rid of the "security" attitude behind everything that is secure. It's a sharing folder, if you restrict people, you will lose people. You password protect, etc, you make it something worth hacking, most hackers want the challenge. Leave it open, just have the Moderators patrol what gets added. Say I submit something today, hold what I submit for a 72 hour period. That way people can look over it, such as the guru's who understand if it is a good table, address, or scaling.
I am deffinitly in support of open, and read access. Write access is what I would secure.
Just my 2 cents. Carry on, and thank you for getting it setup.
If there is one thing to say about the malicious people who would kill an open port access to ROM's etc, it would be because of the access control. How many hacks and virus are on linux open port, and then ask the same question of windows.
My thinking is the number of users that visit this. Leaving it open gets rid of the "security" attitude behind everything that is secure. It's a sharing folder, if you restrict people, you will lose people. You password protect, etc, you make it something worth hacking, most hackers want the challenge. Leave it open, just have the Moderators patrol what gets added. Say I submit something today, hold what I submit for a 72 hour period. That way people can look over it, such as the guru's who understand if it is a good table, address, or scaling.
I am deffinitly in support of open, and read access. Write access is what I would secure.
Just my 2 cents. Carry on, and thank you for getting it setup.
If the answer is a lot to both then its worth going after.