[This email has 3 replies in 1.]
There are several ways; and giving up so easily is extremely *bad*
practice. Making a hacker think a few minutes is better than just
giving them the answer without a blink.
What's more, based on the ease of this process, any remote-server file
processing (be it ASP or PHP or even C scripts) can readily wreck havoc
to the repository, Mr. Rooney. It is more complicated for
remotely-processed scripts to decompile and reengineer binary files than
text files.
In response to Mr. Johnson, the idea of reading revision history is not
at issue. Obviously, it is by design. What alerts me is how the very
purpose of "source code management" and "version control" become
pointless. If revision histories can be easily overwritten then what is
the point of a revision history?! Why not just comment the first 3-4
lines of a file and say "well, I'll burn to CD; that's my version
control". Heck, that would be more reliable as each CD can be its own
revision.
The flaw(?) of the FSFS implementation invalidates its purpose. At the
very least maintaining the revision NUMBER should be important; the
historical details are separate. If the simple revision number is lost,
then the entire implementation fails. A single point of failure is too
risky.
Alas, I am hoping that the FSFS backend gets more robust. If it can go
along the lines of a read-only (except write to add new records)
architecture, then it would definitely serve its purpose better.
To Mr. Mornini, "Was this a serious email (bad) or intended as a joke
(funny)?" It actually was meant to be taken seriously. If the
repositories can act more like write-once/read-forever then it would
actually serve its intended purpose better.
Without getting too carried away, the FSFS can be more robust to
disallow such modifications. If the Subversion Server set checksum
flags when commits are done, for instance, then the Subversion
repositories can at least withstand Notepad.
Nasser Dassi
Sr. Technical Programmer
=========================================
E: ndassi@141xm.com
=========================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 22:42:45 2005