You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2007/03/06 20:27:03 UTC
Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?
> > 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
Re: Has Subversion's attitude toward dataloss changed significantly
since 0.27?
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
>> >> This isn't going to fix the recently posted case of accidentally
>> letting
>> >> a recursive tool make the same edit to the working copy and its
>> >> supposed-to-be pristine counterpart. You probably can't fix that case
>> >> short of a major change to allow the pristine copies to be offset in a
>> >> parallel directory structure, but it would be nice to stop and make
>> the
>> >> problem very obvious if you notice any mtime's newer on the pristine
>> >> copies than they should be - at least if you have anything to indicate
>> >> what they should be.
>> >
>> > Right, but we don't (have a recorded reference). Those files are
>> > marked read-only for a reason. They also have a different extention
>> > for a reason. I'm sorry, but there's no way to do that *and* we can't
>> > prevent every user error in the book.
>>
>> Of course there is a way to do it. CVS wouldn't let a changed file go
>> uncommitted because of some artifact in the local file system.
>
> And it did so by sending *all* local files to the server. You have to
> make trade-offs somewhere...
The value of that tradeoff really depends on how much it is worth to
save sending a bit of data to the server. If you have decent bandwidth
or you are on the same LAN with the server it's probably not enough of a
saving to make it worth the risk of losing your changes when you do a
recursive edit (which seems like a moderately likely thing to happen,
given the location of the pristine copies). Perhaps some future
version could have an option to do a sanity check of the .svn against
the server for people who would prefer a different trade-off. Or
better yet, do the bandwidth savings through an rsync-like transfer
along the lines of backuppc which has its own rsync-in-perl that works
against a compressed copy locally with a stock rsync at the other end,
or rdiff-backup which transfers the differences and stores them in a way
that can reconstruct the older versions. Something like that might even
eliminate the need for the pristine copies for people who don't care
about offline operations.
>> > However, the commits would have
>> > failed if the base file didn't match the base in the repository, so,
>> > other than damaging the administrative area, nothing went wrong there.
>>
>> What do you mean, nothing went wrong? He made a change to files under
>> revision control, committed, and the changes weren't applied to the
>> repository. That's about as wrong as you can get regardless of the
>> reason for it.
>
> I meant no damaged data ended up in the repository.
I'd call it damaged if what is in the repository doesn't match what was
in the committed workspace and you didn't get an error - even if the
commit log says you didn't really commit anything.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/12/07, Les Mikesell <le...@gmail.com> wrote:
> Erik Huelsmann wrote:
>
> >> This isn't going to fix the recently posted case of accidentally letting
> >> a recursive tool make the same edit to the working copy and its
> >> supposed-to-be pristine counterpart. You probably can't fix that case
> >> short of a major change to allow the pristine copies to be offset in a
> >> parallel directory structure, but it would be nice to stop and make the
> >> problem very obvious if you notice any mtime's newer on the pristine
> >> copies than they should be - at least if you have anything to indicate
> >> what they should be.
> >
> > Right, but we don't (have a recorded reference). Those files are
> > marked read-only for a reason. They also have a different extention
> > for a reason. I'm sorry, but there's no way to do that *and* we can't
> > prevent every user error in the book.
>
> Of course there is a way to do it. CVS wouldn't let a changed file go
> uncommitted because of some artifact in the local file system.
And it did so by sending *all* local files to the server. You have to
make trade-offs somewhere...
> > However, the commits would have
> > failed if the base file didn't match the base in the repository, so,
> > other than damaging the administrative area, nothing went wrong there.
>
> What do you mean, nothing went wrong? He made a change to files under
> revision control, committed, and the changes weren't applied to the
> repository. That's about as wrong as you can get regardless of the
> reason for it.
I meant no damaged data ended up in the repository.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly
since 0.27?
Posted by Les Mikesell <le...@gmail.com>.
Garance A Drosihn wrote:
>>> Right, but we don't (have a recorded reference). Those files are
>>> marked read-only for a reason. They also have a different extention
>>> for a reason.
>
> Hrm. Looking at the files under .svn/text-base, I see what you mean.
> But this raises another question: How did my errant 'find' command
> screw me up? Hrm. I guess I should look into that. [time passes...]
You made the same change in your working copy and the hidden pristine
copy because find does directory recursion.
>> What do you mean, nothing went wrong? He made a change to files under
>> revision control, committed, and the changes weren't applied to the
>> repository. That's about as wrong as you can get regardless of the
>> reason for it.
> I may have some possibly better suggestions for this issue, but I need
> to do some more thinking about them. I think I also need to go back and
> regenerate the problem I had, so I can be sure I know exactly what
> happened.
What is supposed to happen on a commit is that the differences between
your changed file and the version you checked out should be sent back to
the repository, and the way it is implemented is that a copy of the
checked-out version is cached under the .svn directory and used to
compute those differences. Since you made identical changes to both
copies, no differences were found, even though your working copy did
differ from the checked out version.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed
significantly since 0.27?
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 3:13 AM -0500 3/12/07, Les Mikesell wrote:
>Erik Huelsmann wrote:
>
>>>This isn't going to fix the recently posted case of accidentally
>>>letting a recursive tool make the same edit to the working copy
>>>and its supposed-to-be pristine counterpart. You probably can't
>>>fix that case short of a major change to allow the pristine copies
>>>to be offset in a parallel directory structure, but it would be
>>>nice to stop and make the problem very obvious if you notice any
>>>mtime's newer on the pristine copies than they should be - at
>>>least if you have anything to indicate what they should be.
>>
>>Right, but we don't (have a recorded reference). Those files are
>>marked read-only for a reason. They also have a different extention
>>for a reason.
Hrm. Looking at the files under .svn/text-base, I see what you mean.
But this raises another question: How did my errant 'find' command
screw me up? Hrm. I guess I should look into that. [time passes...]
Okay, I think I see what happened. The 'find' command executed a
'sed' command, using an edit-in-place option as implemented in
FreeBSD. It looks like that option does something similar to:
sed s/oldString/newString/ filename > filename.new
permit filename.new like filename
rm filename
mv filename.new filename
The way that option does things, it will work without any errors even
when the file is read-only. (I'll have to ask about *that* on the
FreeBSD lists!) However, after doing a few experiments with this
sed-option, I see that it does NOT work if the directory itself is
read-only.
How hard would it be for subversion to make all the '.svn/text-base'
directories be read-only? It would have to know to make the
directory writable when *it* needed to modify things in there, but I
assume that would not add much overhead. Would there be any downside
to making them read-only?
>> I'm sorry, but there's no way to do that *and* we can't prevent
>>every user error in the book.
>
>Of course there is a way to do it. CVS wouldn't let a changed file
>go uncommitted because of some artifact in the local file system.
Well, I think Erik's change *would* have saved me from some of the
problems that I ran into while working on that repository. Maybe it
wouldn't have saved me from the mess I made with the 'find' command,
but it is an improvement and I do believe it would have saved me a
few hours of head-scratching. This is good!
>>However, the commits would have failed if the base file didn't
>>match the base in the repository, so, other than damaging the
>>administrative area, nothing went wrong there.
>What do you mean, nothing went wrong? He made a change to files
>under revision control, committed, and the changes weren't applied
>to the repository. That's about as wrong as you can get regardless
>of the reason for it.
I may have some possibly better suggestions for this issue, but I
need to do some more thinking about them. I think I also need to go
back and regenerate the problem I had, so I can be sure I know
exactly what happened.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly
since 0.27?
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
>> This isn't going to fix the recently posted case of accidentally letting
>> a recursive tool make the same edit to the working copy and its
>> supposed-to-be pristine counterpart. You probably can't fix that case
>> short of a major change to allow the pristine copies to be offset in a
>> parallel directory structure, but it would be nice to stop and make the
>> problem very obvious if you notice any mtime's newer on the pristine
>> copies than they should be - at least if you have anything to indicate
>> what they should be.
>
> Right, but we don't (have a recorded reference). Those files are
> marked read-only for a reason. They also have a different extention
> for a reason. I'm sorry, but there's no way to do that *and* we can't
> prevent every user error in the book.
Of course there is a way to do it. CVS wouldn't let a changed file go
uncommitted because of some artifact in the local file system.
> However, the commits would have
> failed if the base file didn't match the base in the repository, so,
> other than damaging the administrative area, nothing went wrong there.
What do you mean, nothing went wrong? He made a change to files under
revision control, committed, and the changes weren't applied to the
repository. That's about as wrong as you can get regardless of the
reason for it.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/10/07, Les Mikesell <le...@gmail.com> wrote:
> Erik Huelsmann wrote:
> > [re depending on mtime in Subversion]
> >
> > Yesterday I realised that I had an unfinished change in one of my
> > working copies which - when appropriately adjusted - could give us
> > what you want quickly: extend the 'changedness'-heuristic with the
> > factor 'file size'.
> >
> > Since this isn't the first time it has come up in the past weeks
> > (months), I decided to adapt that unfinished change. I committed it
> > this morning as r23767. This means it will be available in 1.5. If you
> > want, you can try backporting it to 1.4. We won't, because it changes
> > the public interface.
>
> This isn't going to fix the recently posted case of accidentally letting
> a recursive tool make the same edit to the working copy and its
> supposed-to-be pristine counterpart. You probably can't fix that case
> short of a major change to allow the pristine copies to be offset in a
> parallel directory structure, but it would be nice to stop and make the
> problem very obvious if you notice any mtime's newer on the pristine
> copies than they should be - at least if you have anything to indicate
> what they should be.
Right, but we don't (have a recorded reference). Those files are
marked read-only for a reason. They also have a different extention
for a reason. I'm sorry, but there's no way to do that *and* we can't
prevent every user error in the book. However, the commits would have
failed if the base file didn't match the base in the repository, so,
other than damaging the administrative area, nothing went wrong there.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly
since 0.27?
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
> [re depending on mtime in Subversion]
>
> Yesterday I realised that I had an unfinished change in one of my
> working copies which - when appropriately adjusted - could give us
> what you want quickly: extend the 'changedness'-heuristic with the
> factor 'file size'.
>
> Since this isn't the first time it has come up in the past weeks
> (months), I decided to adapt that unfinished change. I committed it
> this morning as r23767. This means it will be available in 1.5. If you
> want, you can try backporting it to 1.4. We won't, because it changes
> the public interface.
This isn't going to fix the recently posted case of accidentally letting
a recursive tool make the same edit to the working copy and its
supposed-to-be pristine counterpart. You probably can't fix that case
short of a major change to allow the pristine copies to be offset in a
parallel directory structure, but it would be nice to stop and make the
problem very obvious if you notice any mtime's newer on the pristine
copies than they should be - at least if you have anything to indicate
what they should be.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?
Posted by Erik Huelsmann <eh...@gmail.com>.
[re depending on mtime in Subversion]
> 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.
Yesterday I realised that I had an unfinished change in one of my
working copies which - when appropriately adjusted - could give us
what you want quickly: extend the 'changedness'-heuristic with the
factor 'file size'.
Since this isn't the first time it has come up in the past weeks
(months), I decided to adapt that unfinished change. I committed it
this morning as r23767. This means it will be available in 1.5. If you
want, you can try backporting it to 1.4. We won't, because it changes
the public interface.
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed
significantly since 0.27?
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 9:22 AM +0100 3/21/07, Jan Hendrik wrote:
>Garance A Drosihn wrote on 9 Mar 2007, 16:03, at least in part:
>
>[text is snipped]
>
> > ... Later on, I made a change to one of the source
> > files changed by the find/xargs combo, and when I went to commit
>> *that* change, the 'svn commit' aborted with a message about
>> file-corruption in one of the .svn directories.
>>
> > What apparently had happened was the find/xargs combo had changed
> > both the workarea source file, and the copy of it saved in the
> > .svn directory.
>
>This is pretty old by now and I already saw replies by others (that's
>how Myrealbox worked the last few weeks, hope this gmail will do
>better), but yet I am surprised that unix commands would touch
>hidden directories - that's what .svn folders are, aren't they? -
>except when told so explicitly.
If you do 'find * -etc', then it will skip the .svn directories in
the directory you are in. If you do 'find . -etc', then find starts
at the current directory, and descends into all subdirectories,
including hidden ones such as .svn.
If you want to skip .svn directories, you need to add a few extra
terms to your 'find' command. Eg:
find . -name Makefile\*
becomes:
find . \( -type d -name .svn -false -prune \) -o -name 'Makefile*'
(I guess you don't really need the '-type d' part, but I like to
be extra careful)
> > Garance
>
>Like the flower? :)
I have never seen the flower in real life.
For more trivia WRT the name, see also:
http://www.rpi.edu/~drosehn/Personal/Gad-Name.html
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Has Subversion's attitude towar
Garance A Drosihn wrote on 9 Mar 2007, 16:03, at least in part:
[text is snipped]
> I had a work area checked out, and needed to make the same change to
> many files in the workarea. I used a 'find ... | xargs' command to
> make the change. I compiled everything, and it worked. I did the
> 'svn commit', and that also worked fine. I made some other changes
> and committed those. Later on, I made a change to one of the source
> files changed by the find/xargs combo, and when I went to commit
> *that* change, the 'svn commit' aborted with a message about
> file-corruption in one of the .svn directories.
>
> What apparently had happened was the find/xargs combo had changed both
> the workarea source file, and the copy of it saved in the .svn
> directory. Since both files were changed by a single unix command,
> both copies of the file ended up with the same mtime. So at commit
> time, 'svn' did not realize the file was changed and apparently the
> change to that file was not committed when I thought it was.
This is pretty old by now and I already saw replies by others (that's
how Myrealbox worked the last few weeks, hope this gmail will do
better), but yet I am surprised that unix commands would touch
hidden directories - that's what .svn folders are, aren't they? -
except when told so explicitly. I wonder what result svn update
would have had, now that those files were modified and recognized
as such by SVN again - would it have taken those former non-
committed changes as fresh modifications or overwritten with the
original stuff still in the repository? Having seen some data loss
recently related to mtime this way or another I guess the latter.
We probably can be glad that the find&replace tools we use here
(Homesite, SciTE, a perl script) don't touch the .svn pristine
copies. (BTW as someone run into this by use of a hex editor just
having done a patch in an Apache DLL the clean way, not in SciTE
as I had come to be used to, I can confirm that HxD does not
change mtime either, and I have not found any option for [un]setting
this behaviour. Luckily this file is not under SVN protection!)
[text is snipped]
> Garance
Like the flower? :)
Jan hendrik
> Alistair Drosehn = gad@gilead.netel.rpi.edu
> Senior Systems Programmer or gad@freebsd.org
> Rensselaer Polytechnic Institute or drosih@rpi.edu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For
> additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------
Freedom quote:
Die Berliner Republik ist eine Bürokratenrepublik.
Die Politik stellt sich als reiner Verwaltungsakt unter Sozialingenieuren dar;
ihre höchste Priorität sind Rationalität und Effizienz
im Blick auf gesellschaftliche Ziele, die einfach festgesetzt werden.
Nichts kann sich mehr frei entwickeln.
-- Karen Horn, Die Besserwisser,
Frankfurter Allgemeine Zeitung, 12. März 2007
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed
significantly since 0.27?
Posted by Garance A Drosihn <dr...@rpi.edu>.
Sometime earlier in this thread, it was written:
>
> > > 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 just rejoined this list after a long absence, so I have no idea
what has been covered in this thread. However, one of the reasons I
rejoined is that I had thought I had stumbled upon some serious bug
in subversion. But after a little more investigation into my problem,
I realized what had happened:
I had a work area checked out, and needed to make the same change to
many files in the workarea. I used a 'find ... | xargs' command
to make the change. I compiled everything, and it worked. I did the
'svn commit', and that also worked fine. I made some other changes
and committed those. Later on, I made a change to one of the source
files changed by the find/xargs combo, and when I went to commit
*that* change, the 'svn commit' aborted with a message about
file-corruption in one of the .svn directories.
What apparently had happened was the find/xargs combo had changed
both the workarea source file, and the copy of it saved in the .svn
directory. Since both files were changed by a single unix command,
both copies of the file ended up with the same mtime. So at commit
time, 'svn' did not realize the file was changed and apparently
the change to that file was not committed when I thought it was.
Obviously typo in the find/xargs combo was my fault. And it's my
fault that I didn't notice that the 'svn commit' did not list some
files which had changed, and I guess I should have known they had
changed and noticed they weren't listed. (...but my excuse is that
the commit was changing more than fifty files, and I just didn't
bother to look over the entire list of files to notice if anything
was missing).
However, it was a little disconcerting that 'svn' did not notice there
was a problem until a *later* commit. If this was a normal repo in a
standard development cycle, I wonder how long it would have taken me
to figure out which commit had the real error. What if weeks had
passed between the screwed-up commit and the commit where 'svn'
finally noticed that things were screwed up?
It happens that I was building a new repo from a motley collection of
old patch files, and I figured the only safe way to do that was to
repeatedly re-create the entire repo from scratch until I was sure I
had all the patches applied in the right order. So I had a script
which started out by creating a brand new repo, and then applied each
of updates, and did the appropriate commits. Given that I could
easily re-create every commit the repository had ever seen, it was
pretty easy for me to figure out what had happened.
Once I realized that svn was making a decision based on mtime-checking,
I also changed my script to put a "sleep 1" between each commit, just to
make sure the mtime's were changing! And in fact my first few attempts
to run this script had hit other problems due to this mtime-checking,
but I had figured a way around those problems without understanding
what was causing them.
> > I'm sorry you feel disappointed and of course 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 will admit that I don't know enough about the internals of svn to
even know what to suggest yet. I'm not even sure if I should file
this in the official bug-reporting database. I want to think about
it some more before I do that, but I thought I'd at least mention it
as long as mtime-checking seemed to be a topic for discussion here...
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?
Posted by Jan Hendrik <ja...@myrealbox.com>.
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