> > 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.
> 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.
> (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).
> 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...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 6 21:27:30 2007