Concerning Re: Has Subversion's attitude towar
Erik Huelsmann wrote on 6 Mar 2007, 21:27, at least in part:
> > > These posts bare no relation to the original subject in the thread
> > > anymore. I think the Original Poster has gotten a response and we
> > > can call this thread concluded.
>
> I said that in a previous mail. I still think that's true, so, I
> changed the topic and I hope GMail breaks threading too.
Changing the topic at this point practically kills it as the whole
bunch of previous arguments is lost, except of course if gmail & co.
do respect the in-reply-to headers. Besides I would have not
considered the thread as gone off-topic, rather shifted to a broader
angle at Subversion's use and non-use of mtime.
> > 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,
> > ...
>
> This is still the issue, but, ofcourse within the limits of what might
> be expected from Subversion.
>
> > ...these days to me it rather looks like the user has to go
> > to the moon himself to accomodate Subversion.
>
> Well, let me start by saying that many of those users are requesting
> things which may not reasonably be expected from Subversion: If you
> want to stay in orbit for a few days, the tool you need looks somewhat
> like a plain, but in fact is a space shuttle. Even though both share
> the requirement that they should support a flight from (large) heights
> back to earth, they're really different 'tools'.
>
> The resistance you're seeing is - I believe - related to the fact that
> some think that if Subversion makes a great satellite, you may be able
> to partially address problems with it, but if you actually need an ISS
> space station, you can't grow that from Subversion. We call that
> feature creep: the fact that many are asking for features which are
> related to the task they use Subversion for, but not really related to
> version control.
Well said. I understand this creeping issue, I see this sort of
arguments on the SciTE and Pegasus Mail lists, too, requesting
making a great email app a calendar, message board, news
reader, and what else, only because some other app does it while
being a rather poor mail client. Or a full-fledged IDE out of a very
capable and very fast editor.
When I keep my argument then not for the reason I run into this
issue. I understand where we run into it and where we have to
change things, maybe not as much as proposed here, but enough
to suit our needs. And certainly without requiring us going to the
moon. We are working on it, though without haste.
I think of it in a broader, more general way. And I keep saying that
Subversion can't on one side say that mtime is unreliable, useless,
worthless, and then on the other side takes the awful chance of
making its first and vital decision on just that. And it is one thing
not to commit changed files with unchanged mtime, but quite
another to overwrite such files on update, even if the filesize has
changed. A plain, general purpose file synchronizer like Total
Commander at least takes two parameters into consideration.
That still leaves a chance. Someone said that rsync and tar
handle this since long, and rsync still is said to be extremely fast.
A tool that puts so much aim in claiming to protect any bit of user
data like Subversion does should at least not fall behind tools with
a lesser claim in this field. That's the whole point of it.
You have me think about using Subversion here once more. We
don't do source code here except for a few scripts, and we don't
need tagging, and history is of minor interest. We also quickly
gave up on branching because of issues when used on files with
eol-style set to native, rather check out a separate WC for big
tasks. What we need is something that allows for concurrently
working on HTML/PHP/JPEG/Perl/Python files, using a couple of
apps like Homesite, SciTE, EditPad, Notepad2, Paintshop, that is
the apps we have used before and want to continue to use for their
flexibility. We don't wanna have some huge all-purpose application
cooking the tea for us on the side, too.
Actually we had trashed Subversion before for having far too many
issues in operation. That was at ver. 1.0x, after having gone
through with it from ver. .27 on. Synching with TotalCommander &
WinMerge took some more effort, but not that much more time
considering fiddling with the Subversion issues back then. Only
after adding another machine this became more cumbersome and
we gave Subversion another try. We had very few and mostly only
minor issues this time so far. The biggest one, much more
annoying than our occasional trouble with mtime deliberately set
back, was having to take Python code out as Subversion would not
automerge it.
> > (And it seems
> > fitting that TortoiseSVN has selection/confirmation dialogs for
> > about everything but delete.) My case of deliberately setting back
> > mtime may be special, but AFAIU recode preserves mtime by default
> > and isn't just another foolish, outdated Windows editor/tool any
> > reasonable guy can and should neglect to take care of.
>
> Not to be your average problematic kind of guy, but recode isn't your
> average use of file transforms in a version control process (but
> that's just my estimate).
Alright, I just named recode here as someone had run into the
mtime issue by using it. I have not used it, though I suppose tools
like it will become more broadly used with the spread of unicode
and the necessity to convert old data. Someone else run into
mtime trouble by way of a hex editor. Again I have not used that
specific editor, but years back (DOS/WfW3.11 times) I run into
trouble as hacking an executable had modified the timestamp -
setting it back to the original time had the hack work immediately.
So I suppose hex editors have a very legitimate purpose to keep
original mtime intact.
But people don't start using Subversion and then choose the work
they have to do and the applications they can use for work and with
Subversion. It's rather on the contrary: people do their work, and
they do it with a set of applications they found useful for their
purpose and got used to. And then one day they find that too often
they run into trouble, working in a group on the same set of files,
that e.g. the locking mechanisms of the database or word
processor are either not existant or not sufficient, and then they
come to a tool like Subversion. Else they would not come to
Subversion. Else they would go for or stick to a highly integrated
solution that breaks the moment someone attempts to use another
editor for the quick fix of the typo in line 23.
I repeat: not every situation, not every possibly queer environment
can be anticipated. But I also repeat: a tool with such a claim on
user data protection as Subvervion makes should go out of its way
to at least take no more chances than many an average tool does,
to at least consider a second parameter for such a vital decision.
Any chain is just as strong as its weakest link and to your own
argument mtime is very weak. So general data handling of
Subversion can be as strong and good as it may be if already the
first link, this first test for all following action, is solely based on
just this. Not only at commit time, but also at update time, with
the result of destructive data loss.
Not on the line of Subversion's internal operation and the grade of
data protection it provides, but general usability another one's
argument for using mtime instead of checkout/commit time was
the possibility to see at a quick glance if a file can contain any
piece of recent code. I like to do this myself to see if a .doc file
dates back to Word 6 days with a very specific issue if opened in
Word97. Or to quickly see if a JPEG still originates from the old
scanner or was already replaced by a high-quality photo.
> > I probably
> > should be aware from the start that deliberately working on mtime
> > might have unwanted side effects, an average user of a tool like
> > recode has no good reason to expect issues with Subversion.
>
> > Of course it is impossible to prepare for any circumstance, but on
> > one hand we constantly get told mtime is unreliable and useless
> > while on the other hand Subversion just takes chances on this very
> > mtime without taking into account any other parameter for making
> > vital decisions. That's quite strange.
>
> Subversion is built on the assumption that mtime is unreliable, with
> the exception that it expects mtime to have changed when the file has
> changed. In an average work-cycle (and even in not-so-average work
> cycles), that's a reasonable assumption. If the file has stayed the
> same, there's no problem with the mtime being changed. Subversion
> won't commit the file.
>
> I'm sorry you feel disappointed and ofcourse you're free to submit
> patches which give Subversion better 'changedness' heuristics, but
> please, make sure they don't come at an extra cost: Subversion isn't
> very bareable for many windows users of corporate projects as it is...
I would. I also have noticed with pleasure the gain in performance
since ver. 1. Unfortunately I can just handle our own limited
scripting needs in Perl & Python. If and when I get the observer
status I will file the issue concerning modified files being written
over without notification if mtime has not changed, even if their
filesize has changed, as futile as it seems at this point. I will not
waste anyone's or my time any further on this topic as I think
everything has been said on each side to a degree we have to
agree to disagree, leaving the argument as it is.
Best regards,
Jan Hendrik
---------------------------------------
Freedom quote:
We do not move forward by curtailing people's liberty
because we are afraid of what they may do or say.
-- Eleanor Roosevelt, The Nation, 1940
---------------------------------------------------------------------
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:00 2007