It's a wonderful thing to get a reply to a posting I have yet to receive
myself! Thank God this MarvellousRapidBox will die in a fortnight -
I'll rather prefer having no halfway personal/private email than going
on with MyRealBox, testbed or not.
Concerning Re: Is there really no way to keep
Jeff Smith wrote on 6 Mar 2007, 11:13, at least in part:
> On Tuesday 06 March 2007 09:45, Jan Hendrik wrote:
> > > But chances are slim this actually happens: of all 2^31 seconds in
> > > a time_t, the damage would have to fall exactly on that second...
> >
> > Chances are an evil thing to build upon. Overhere chances are
> > great we tread onto each other's feet for quite a lot webfiles.
> > Except for one single file chances are very low we conflict on Word
> > files. Chances are almost null for concurrent editing of the same
> > JPG file. And chances are actually null for conflicts with RAW
> > photo files - as the RAW editor is installed on exactly one machine.
>
> Hey Jan, great point! That is EXACTLY why we are advising against the
> way you said you are using subversion. You are leaving yourself to
> chance, and subversion does not have this problem if you use it
> correctly.
Jeff, I understand the weak spots of the use here (actually the use
is weak-spotted only about once or twice in a month or two, though
this can prove one weak spot too much) and am working on it,
though I already begin to understand the weak spots of the setup
proposed by you and others. There are quite a few considerations
still to be discussed here. Updating the remote live server on the
ISP's site in one rush with the dedicated "master" WC by post-
commit hook actually is not such a good thing in practice due to
an extended overhead for necessary error handling and other
issues. Better separating the tasks.
Anyway, we can leave my use of Subversion out of it for this
arguement as long as even a tool that is just a filemanager with
built-in FTP client (Total Commander), which has no special aim in
protecting user data beyond the resonable and basic level of any
such tool, always takes *two* parameters into account before
proposing synching action: mtime *and* filesize. This still takes
chances, but less. And at least on local operation it offers the
option to force a byte-by-byte comparison. AFAIK WinMerge
takes no chances at all and always compares, either byte-by-byte
or checksum, I don't know. I have yet to play with it, but from what
I understand rsync operates on a similar basis and still is
exceptionally fast.
> > I don't follow the list as closely as I did between versions .27 &
> > 1.0 (it was just the dev list of course, users came in only later)
> > and therefore appologize if I am mistaken, but from some recent
> > postings I got the impression that the philosophy behind Subversion
> > has turned by 180 degrees since. Back then it was always that
> > Subversion would go to the moon to prevent any loss of user data,
> > these days to me it rather looks like the user has to go to the moon
> > himself to accomodate Subversion.
>
> From what I learned in your situation, you have actually "gone to the
> moon" to create your risky environmen. The chance does not exist in
> the case where there is one user per WC and one system clock which is
> used when a file is edited, and no faulty tools used (which try to
> preserve the mtime when in fact the file was modified). In those ways
> there is currently nothing wrong with subversion.
Before using Subversion (again) I always had *two* parameters
checked, only the addition of Subversion doubled the risk by only
checking *one* parameter. The joining of Subversion WCs with a
remote live server hosted by an ISP without SVN option - thus kind
of mirror of a WC stripped off of the .svn meta stuff - may indeed
sound a far and strange way for many.
What I am referring to by the user having to go to the moon,
however, is that there happens to be a growing list of tools and
programs users obviously have to abandon to use Subversion
properly. Just saw a posting on this very same issue, only caused
by a hex editor. In the attempt not to break applications the editor
breaks use of subversion. So users will have to do extensive tests
before using any application in connection with Subversion to make
sure it works out and their data is not lost - as I said: they have to
go to the moon.
One great point of Subversion, at least back at ver. .27, was that it
is not tightly integrated into some IDE, but works with every editing
environment, by this greatly compensating for what such lack of
tight integration with but one application might mean in less
comfort. Well, obviously there are limits.
JH
---------------------------------------
Freedom quote:
A wise and frugal government, which shall restrain men from
injuring one another, which shall leave them otherwise free to
regulate their own pursuits of industry and improvement, and shall
not take from the mouth of labor the bread it has earned. This is
the sum of good government, and all that is necessary to close the
circle of our felicities.
-- Thomas Jefferson, in his 1801 inaugural address
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 9 12:50:21 2007