Re: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links

[Stefan Sperling]

On Tue, Feb 14, 2012 at 01:54:22PM +0100, christian.asmus...@ubs.com wrote:
> Dear *,
> 
> I was happy to see subversion 1.7.3 was release and that many bugs were
> fixed.
> 
> This bug did not get fixed though
> (http://subversion.tigris.org/issues/show_bug.cgi?id=4052) and that
> would have made me even happier J
>
> Has anyone had time to look into this?

Hi Christian,

I found some time to look into this and have committed a fix
and nominated the same for backport to the 1.7.x branch.

If you need this fix ASAP and you compile your own builds you
can apply the patch below.

Index: subversion/libsvn_client/merge.c
===
--- subversion/libsvn_client/merge.c(revision 1245286)
+++ subversion/libsvn_client/merge.c(working copy)
@@ -48,6 +48,7 @@
 #include "svn_props.h"
 #include "svn_time.h"
 #include "svn_sorts.h"
+#include "svn_subst.h"
 #include "svn_ra.h"
 #include "client.h"
 #include "mergeinfo.h"
@@ -1861,10 +1862,14 @@ files_same_p(svn_boolean_t *same,
   working_rev.kind = svn_opt_revision_working;
 
   /* Compare the file content, translating 'mine' to 'normal' form. */
-  SVN_ERR(svn_client__get_normalized_stream(&mine_stream, wc_ctx,
-mine_abspath, &working_rev,
-FALSE, TRUE, NULL, NULL,
-scratch_pool, scratch_pool));
+  if (svn_prop_get_value(working_props, SVN_PROP_SPECIAL) != NULL)
+SVN_ERR(svn_subst_read_specialfile(&mine_stream, mine_abspath,
+   scratch_pool, scratch_pool));
+  else
+SVN_ERR(svn_client__get_normalized_stream(&mine_stream, wc_ctx,
+  mine_abspath, &working_rev,
+  FALSE, TRUE, NULL, NULL,
+  scratch_pool, scratch_pool));
 
   SVN_ERR(svn_stream_open_readonly(&older_stream, older_abspath,
scratch_pool, scratch_pool));

Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals

[C. Michael Pilato]

Alexey,

We ask that folks send questions, concerns, and potential bug reports to
users@subversion.apache.org.  (I've taken the liberty of dropping dev@ and
adding users@ to the distribution list of this response so that follow-ups
go to the right place.)

I wasn't able to easily reproduce this using Linux and a trunk version of
the codebase.  (I know that's two strikes against me in terms of trying to
match your scenario.  My 1.7 client build is horked at the moment, though.) 
One thing that comes to mind with the situation you are seeing is the
possibility that an anti-virus software could be actively scanning the
temporary files that Subversion creates and, in doing so, blocking access to
those files from Subversion.  Most modern anti-virus software packages offer
a "snooze" feature of sorts -- you might try temporarily disabling your AV
package and re-trying the checkout.  If all goes well, consider adding your
checkout area to the AV package's list of excluded scan directories.

Good luck.

On 02/16/2012 12:27 PM, Alexey 0 Moudrick wrote:
> Hello, dev,
>
> I've encountered an issue with *svn copy* command.
> I report it here because I did not find a way to report in in the issue
> tracker .
> It cannot copy a directory by its url to local working copy if the
> directory contains valid svn:external property.
> Instead of correct copying, it shows error like this:
>
> *svn: E720005: Can't move* 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> 'C:\t\wc\externals-container-copy': *Access is denied.*
>
> The *repro.bat* composed according to recommendations
>  is
> attached (please rename it to repro.bat).
>
> *operating systems* where I tested:
>
> *Windows 7 Professional* x86-32bit SP1 Microsoft Windows [Version 6.1.7601]
> *Windows Server 2008 R2* Standard x64-64bit SP1 Standard Microsoft Windows
> [Version 6.1.7601]
>
> *svn versions* where I tested:
>
> svn, version *1.7.2* (r1207936)
>compiled Nov 30 2011, 02:05:23
>
> svn, version *1.7.1* (r1186859)
>compiled Oct 28 2011, 13:40:58
>
> Additionaly, this makes svncopy.pl
> 
> contribution script fail on this error.
>
> Full output of repro.bat:
>
> C:\t>*repro.bat*
> Base url for repo: file:///C:/t/repos
> Making a tree for import...
> Importing it...
> Checking out working copy..
> *Creating valid svn:externals property...*
> property 'svn:externals' set on 'wc\externals-container'
> Sendingwc\externals-container
>
> Committed revision 2.
> *Copying externals container from URL to WC*
>  U   wc\externals-container-copy
>
> Fetching external item into 'wc\externals-container-copy\ext1':
> Checked out external at revision 2.
>
>
> Fetching external item into 'wc\externals-container-copy\ext2':
> Checked out external at revision 2.
>
> Checked out revision 2.
> *svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-169DB674' to
> 'C:\t\wc\externals-container-copy': Access is denied.*
> *
> *
> -- 
> 
> Best Regards
> Alexey 0 Moudrick
> =


-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Jason Wong wrote on Thu, Feb 16, 2012 at 11:42:42 -0800:
> On Wed, Feb 15, 2012 at 6:15 PM, Daniel Shahaf  wrote:
> > Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
> >> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia  wrote:
> >> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf  wrote:
> >> >> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
> >> >>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
> >> >
> >> >>> Get xxd.exe from http://www.vim.org/ and cat.exe and sed.exe from
> >> >>> http://gnuwin32.sf.net (or from Cygwin).  Delete from the script the
> >> >>> line that uses the 'head' command.
> >> >>
> >> >> There is a second use of 'head', which you shouldn't delete.  So
> >> >> instead, just get head.exe from the same place as the other two, or use
> >> >> the following kind of statement:
> >> >
> >> > Or install CygWin and run the scripts from inside CygWin. This does
> >> > present end-of-line issues, so be very careful about using "svn:eol
> >> > native" properties.
> >> >
> >> >>
> >> >>my $line = do {
> >> >>open FOO, "perl -V 2>&1 |";
> >> >>;
> >> >>};
> >> >>
> >> >> Lastly, there's a 'sed' invocation that uses single-quoted arguments.
> >> >> All it does is "print the input up to the first empty line" --- feel
> >> >> free to implement it differently.  (One way:
> >> >>
> >> >>my @lines = split /\n/, `command | goes | here`;
> >> >>$_ and print or last for @lines;
> >> >>
> >> >> Both of these examples could do with some error checking.)
> >> >>
> >> >> Daniel
> >> >> (yes, there's also a neater way to do this without split(). but it's
> >> >> not a Perl class here)
> >>
> >> Hello.
> >>
> >> Sorry for the delay. Here is an update of what I have done since
> >> the last time I posted.
> >>
> >> I have run "svn log -q ^/" on the respository and it came back with
> >> no missing revisions.
> >>
> >
> > I stand corrected, then.  I've confirmed on another instance of the bug
> > that 'svn log -q ^/' does not behave abnormally when the bug is present.
> > Sorry for the misinformation.
> >
> > Question to devs: what operation will walk the predecessor links for
> > the root fspath? (and can therefore be used to identify instances of
> > the bug)
> >
> >> Since I first posted, each of the projects we have tried to build
> >> that had failed have since successfully been built without any changes
> >> on our side.
> >>
> >
> > What is the significance of this?  I don't know how your build process
> > interacts with Subversion.
> >
> >> I was having an issue with converting the script to run in windows as
> >> I was only getting the first line returned so I set up cygwin.
> >>
> >> I ran the script against both of the revisions (61815 and 61852) in
> >> mentioned in the Apache error log and the output was the same for
> >> each.
> >>
> >> Commands:
> >>dump-noderev.pl /repository
> >> /project/binaries/release/phase1/iteration/81/trunk 61815
> >>dump-noderev.pl /repository
> >> /project/binaries/release/phase1/iteration/81/trunk 61852
> >>
> >> Output:
> >>id: 9-45362.0-61242.r61424/0
> >>type: dir
> >>pred: 9-45362.0-60310/0
> >
> > Are you sure that's the value of the pred: field?  It contains only
> > one ".", instead of two.
> >
> 
> I missed a part of it, you are right. here is the full pred line:
>pred: 9-45362.0-60310.r60310/0
> 

Okay.  Did /project/binaries/release/phase1/iteration/81/trunk@61852, or
anything under it, change between r60311 and r61423?  (I'm intentionally
using the peg rev notation here --- these id's do not change when
a parent of the path in question gets copied.)

> >>count: 43
> >>text: 58741 121716266 218 218 74eb31e90880ba1345fc49252ca6efe6
> >>cpath: /project/binaries/release/phase1/iteration/81/trunk
> >>copyfrom: 61423 /project/binaries/release/phase1/iteration/80/trunk
> >>
> >> Is this information helpful? Let me know if this tells you anything. Thanks
> >>
> >
> > The fact that the output is identical suggests that the
> > /project/binaries/release/phase1/iteration/81/trunk tree hasn't changed
> > between those two revisions (or that there was a directory replace above
> > it).
> >
> > However, this is the error you report:
> >
> > [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] predecessor 
> > count for the root node-revision is wrong: found 61815, committing r61852  
> > [409, #160004]
> >
> > The metadata this error complains about will be output by these two
> > commands:
> >
> >  ./dump-noderev.pl /repository / 61851
> --
> 
> id: 0.0.r61851/33470
> type: dir
> pred: 0.0.r61850/3844
> count: 61818
> text: 61851 32225 1232 1232 7555349571e297c23e647cc2441d5b8f
> cpath: /
> copyroot: 0 /
> minfo-cnt: 25685
> --
> 
> >  ./dump-noderev.pl /repository / 61852
> --
> 
> id: 0.0.r61852/27663
> type: dir
> pred: 0.0.r61851/33470
> count: 61819
> text: 61852 26417 1233 

Re: predecessor count for the root node-revision is wrong message

[Jason Wong]

On Wed, Feb 15, 2012 at 6:15 PM, Daniel Shahaf  wrote:
> Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
>> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia  wrote:
>> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf  wrote:
>> >> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
>> >>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
>> >
>> >>> Get xxd.exe from http://www.vim.org/ and cat.exe and sed.exe from
>> >>> http://gnuwin32.sf.net (or from Cygwin).  Delete from the script the
>> >>> line that uses the 'head' command.
>> >>
>> >> There is a second use of 'head', which you shouldn't delete.  So
>> >> instead, just get head.exe from the same place as the other two, or use
>> >> the following kind of statement:
>> >
>> > Or install CygWin and run the scripts from inside CygWin. This does
>> > present end-of-line issues, so be very careful about using "svn:eol
>> > native" properties.
>> >
>> >>
>> >>my $line = do {
>> >>open FOO, "perl -V 2>&1 |";
>> >>;
>> >>};
>> >>
>> >> Lastly, there's a 'sed' invocation that uses single-quoted arguments.
>> >> All it does is "print the input up to the first empty line" --- feel
>> >> free to implement it differently.  (One way:
>> >>
>> >>my @lines = split /\n/, `command | goes | here`;
>> >>$_ and print or last for @lines;
>> >>
>> >> Both of these examples could do with some error checking.)
>> >>
>> >> Daniel
>> >> (yes, there's also a neater way to do this without split(). but it's
>> >> not a Perl class here)
>>
>> Hello.
>>
>> Sorry for the delay. Here is an update of what I have done since
>> the last time I posted.
>>
>> I have run "svn log -q ^/" on the respository and it came back with
>> no missing revisions.
>>
>
> I stand corrected, then.  I've confirmed on another instance of the bug
> that 'svn log -q ^/' does not behave abnormally when the bug is present.
> Sorry for the misinformation.
>
> Question to devs: what operation will walk the predecessor links for
> the root fspath? (and can therefore be used to identify instances of
> the bug)
>
>> Since I first posted, each of the projects we have tried to build
>> that had failed have since successfully been built without any changes
>> on our side.
>>
>
> What is the significance of this?  I don't know how your build process
> interacts with Subversion.
>
>> I was having an issue with converting the script to run in windows as
>> I was only getting the first line returned so I set up cygwin.
>>
>> I ran the script against both of the revisions (61815 and 61852) in
>> mentioned in the Apache error log and the output was the same for
>> each.
>>
>> Commands:
>>dump-noderev.pl /repository
>> /project/binaries/release/phase1/iteration/81/trunk 61815
>>dump-noderev.pl /repository
>> /project/binaries/release/phase1/iteration/81/trunk 61852
>>
>> Output:
>>id: 9-45362.0-61242.r61424/0
>>type: dir
>>pred: 9-45362.0-60310/0
>
> Are you sure that's the value of the pred: field?  It contains only
> one ".", instead of two.
>

I missed a part of it, you are right. here is the full pred line:
   pred: 9-45362.0-60310.r60310/0

>>count: 43
>>text: 58741 121716266 218 218 74eb31e90880ba1345fc49252ca6efe6
>>cpath: /project/binaries/release/phase1/iteration/81/trunk
>>copyfrom: 61423 /project/binaries/release/phase1/iteration/80/trunk
>>
>> Is this information helpful? Let me know if this tells you anything. Thanks
>>
>
> The fact that the output is identical suggests that the
> /project/binaries/release/phase1/iteration/81/trunk tree hasn't changed
> between those two revisions (or that there was a directory replace above
> it).
>
> However, this is the error you report:
>
> [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] predecessor count 
> for the root node-revision is wrong: found 61815, committing r61852  [409, 
> #160004]
>
> The metadata this error complains about will be output by these two
> commands:
>
>  ./dump-noderev.pl /repository / 61851
--

id: 0.0.r61851/33470
type: dir
pred: 0.0.r61850/3844
count: 61818
text: 61851 32225 1232 1232 7555349571e297c23e647cc2441d5b8f
cpath: /
copyroot: 0 /
minfo-cnt: 25685
--

>  ./dump-noderev.pl /repository / 61852
--

id: 0.0.r61852/27663
type: dir
pred: 0.0.r61851/33470
count: 61819
text: 61852 26417 1233 1233 712fec619d55677e67aca8f7aa4ceb97
cpath: /
copyroot: 0 /
minfo-cnt: 25685


>
>> Jason.
>
> Cheers,
>
> Daniel
>

Hi Daniel

Thanks for the quick reply. I have posted the results from the two
commands you have asked me to run above as well as the full pred
value that was incomplete.

Let me know if you need any other information.
Thanks.

Jason

Re: ran get-location-segments.py returns 0

[Stefan Sperling]

On Sun, Feb 12, 2012 at 09:20:31AM +, Rokhkin, IlyaX wrote:
> What should I do to define removed and added files with the same name in 
> allover repository?
> What command should I run? 

There is no command that will give you the answer straight away.
You will need to perform some processing on results you get from
Subversion commands.

I suppose parsing and processing the output of 'svn log -v --xml'
might help. But I cannot be sure because I don't understand what
problem you are really trying to solve here. What do you need this
list of files for?

RE: ran get-location-segments.py returns 0

[Rokhkin, IlyaX]

Anyone can assist here?

Regards,
Ilya Rokhkin
Configuration Management Engineer
Intel - Data, storage and SW Team
iNET: 8-920-6165
Tel: +972-3-9296165

From: Rokhkin, IlyaX
Sent: Thursday, February 09, 2012 17:49
To: users@subversion.apache.org
Subject: ran get-location-segments.py returns 0

1/16/2012 7:23 AM | ilyax Rokhkin

Hi,

I ran get-location-segments.py to the hole repository, but nothing was found
What it means I wrong used the tool, as I know for sure that there is replaced 
(R) files in the repo, where old history and file gone and new file was added 
by merge command:
/usr/intel/pkgs/python/2.4/bin/python 
/nfs/iil/home/irokhk1x/shared/get-location-segments.py 
file:///nfs/iil/proj/mpg/svn_av_repo/tests
r0-r299042: (null)

What is the problem I know for sure there are files that was removed and 
imported with the same name
Can you please assist me?

Regards,
Ilya Rokhkin
Configuration Management Engineer
Intel - Data, storage and SW Team
iNET: 8-920-6165
Tel: +972-3-9296165

-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Subversion 1.7 symlink problems

[Daniel Shahaf]

At a guess the problem here is that 'status' dereferences the symlink
when it shouldn't or didn't, so I don't think this is related to #4091.

Could you file a new issue for this?  And, if possible, provide
a reproduction script.

Thanks,

Daniel


Fridtjof Busse wrote on Thu, Feb 16, 2012 at 16:02:19 +0100:
> Hi,
> 
> we've started to test Subversion 1.7.3 on linux and noticed a somewhat 
> drastaic change in svn behavior.
> Our repo (also 1.7, a svnsync copy) contains a lot of symlinks and externals. 
> Different from Subversion 1.6, every one of those symlinks shows up as "M" in 
> "svn status".
> "svn diff" chokes on those files (which point to an external dir), like this:
> svn: E21: Can't read file '/home/fbusse/repo/symlinktests/link': Is a 
> directory
> 
> "link" is a symlink to a directory one level up.
> 
> "svn commit" also fails with this:
> svn: E145001: Commit failed (details follow):
> svn: E145001: Entry '/home/fbusse/repo/symlinktests/link' has unexpectedly 
> changed special status
> 
> Any ideas? It looks very much like a bug, might be related to issue 4091.
> 
> Please CC me, thanks.
> 
> -- 
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: a question about "svn del"

[Daniel Shahaf]

Ulrich Eckhardt wrote on Thu, Feb 16, 2012 at 16:15:54 +0100:
> Am 16.02.2012 15:18, schrieb frame:
> >In my local area, if I want to delete a directory:
> >
> >svn del junk_dir
> >
> >svn commit junk_dir -m "deleted it"
> 
> Just wondering, don't you have to commit the parent dir?
> 

Under the hood, yes.  But I assume the client library might be taking
care of this particular detail.

Re: SVN backup with lvm snapshots and rsync

[Daniel Shahaf]

Stefan Sperling wrote on Thu, Feb 16, 2012 at 13:53:04 +0100:
> On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote:
> > Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
> > > On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
> > >  wrote:
> > > > Nico Kadel-Garcia  writes:
> > > >
> > > >> Unless you do a "sync"
> > > >> command, or various low level flush commands, you don't know that you
> > > >> write to disk has actually made it to the platter.
> > > >
> > > > Subversion does that.  It uses fsync (plus fsync on directories on
> > > > Linux) before assuming data is on disk.
> > > 
> > > So the risk is reduced, which is good. It lowers the window of
> > > vulnerability (between when a commit is published, and when the fsync
> > > occurs). This is actually good progamming. Not everyone who deals with
> > > real data is this thoughtful.
> > 
> > There is no "window of vulnerability".
> 
> There is in the case where the operating system or disk lies to the
> application about data having been stored on platters.
> 

Stefan, you're correct, it would have been more accurate for me to say
"There is no window of vulnerability if specific system calls that
Subversion uses fulfill their contract".

It's just that getting to this level of detail seemed to be more
hair-splitting than was necessary for me to rebut Nico's point.

Thanks for clarifying.

> 
> I am not saying Subversion is careless. There is nothing Subversion
> can do about any of this. But these are things to consider when
> building a system for high reliability purposes. The systems are
> complex and the less complexity you've got the more reliability you
> tend to get.

Re: a question about "svn del"

[Ulrich Eckhardt]

Am 16.02.2012 15:18, schrieb frame:

In my local area, if I want to delete a directory:

svn del junk_dir

svn commit junk_dir -m "deleted it"


Just wondering, don't you have to commit the parent dir?



Now, if another person(or me in another computer) updated his local
area, junk_dir is still in his local area, but not versioned. However,
*sometimes* I saw junk_dir is completely deleted in the local area by
svn during update. So the puzzle in my mind is why sometimes junk_dir
still in another person's local, but unversioned and sometimes
automatically deleted in his local area.


SVN's credo: Do not destroy a user's changes! If create a local change 
inside that folder, be it adding a file (not svn add'ing!) or modifying 
one, SVN will not delete those changes. So, if your folder was "clean", 
it will be automatically removed, any other changes will be preserved.


Uli

**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Subversion 1.7 symlink problems

[Fridtjof Busse]

Hi,

we've started to test Subversion 1.7.3 on linux and noticed a somewhat drastaic 
change in svn behavior.
Our repo (also 1.7, a svnsync copy) contains a lot of symlinks and externals. 
Different from Subversion 1.6, every one of those symlinks shows up as "M" in 
"svn status".
"svn diff" chokes on those files (which point to an external dir), like this:
svn: E21: Can't read file '/home/fbusse/repo/symlinktests/link': Is a 
directory

"link" is a symlink to a directory one level up.

"svn commit" also fails with this:
svn: E145001: Commit failed (details follow):
svn: E145001: Entry '/home/fbusse/repo/symlinktests/link' has unexpectedly 
changed special status

Any ideas? It looks very much like a bug, might be related to issue 4091.

Please CC me, thanks.

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

a question about "svn del"

[frame]

Hi:

I have been using subversion for several years. One thing I don't
really understand is "svn del":

In my local area, if I want to delete a directory:

svn del junk_dir

svn commit junk_dir -m "deleted it"

Now, if another person(or me in another computer) updated his local
area, junk_dir is still in his local area, but not versioned. However,
*sometimes* I saw junk_dir is completely deleted in the local area by
svn during update. So the puzzle in my mind is why sometimes junk_dir
still in another person's local, but unversioned and sometimes
automatically deleted in his local area.

Thank you very much.

I got an error, is this serious?

[x'shshui zh]

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 'D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversio
 n\libsvn_wc\wc_db.c'
 line 1597: assertion failed (SVN_IS_VALID_REVNUM(changed_rev))

__

I just checkout some code from https://bitbucket.org/id804097/minnaedu.
On that page ,it is suggested that use "hg clone". then, I learned that
"svn checkout" may work, I try it on my windows 7.
what I surely curtain is that my network is really bad, when downloading
the
code it just reached 100+ bytes/sec.

Re: SVN backup with lvm snapshots and rsync

[Les Mikesell]

On Thu, Feb 16, 2012 at 6:53 AM, Stefan Sperling  wrote:

> >
> > There is no "window of vulnerability".
>
>
> What if the disk controller lies and sends the acknowledgement before
> the actual work has completed (e.g. it cached the write request and is
> going to get to it soon)? How can the OS know what the disk controller
> is really doing?
>

That is a risk in the case of a power failure with a disk/raid controller
that has a cache without battery backup, but in the case of an LVM snapshot
and the power staying on, wouldn't the controller return the cached block
regardless of whether it had made the round trip to disk or not?

-- 
   Les Mikesell
 lesmikes...@gmail.com

Re: SVN backup with lvm snapshots and rsync

[Stefan Sperling]

On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote:
> Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
> > On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
> >  wrote:
> > > Nico Kadel-Garcia  writes:
> > >
> > >> Unless you do a "sync"
> > >> command, or various low level flush commands, you don't know that you
> > >> write to disk has actually made it to the platter.
> > >
> > > Subversion does that.  It uses fsync (plus fsync on directories on
> > > Linux) before assuming data is on disk.
> > 
> > So the risk is reduced, which is good. It lowers the window of
> > vulnerability (between when a commit is published, and when the fsync
> > occurs). This is actually good progamming. Not everyone who deals with
> > real data is this thoughtful.
> 
> There is no "window of vulnerability".

There is in the case where the operating system or disk lies to the
application about data having been stored on platters.

E.g. it depends on how long the OS blocks the application during fsync.
Will it make the app wait all the way until the disk controller sent
an acknowledgement interrupt for the write? Or will it allow the
application to continue as soon as the buffer no cache no longer
considers the buffer dirty because it issued a write? This descision
is entirely up to the OS.

What if the disk controller lies and sends the acknowledgement before
the actual work has completed (e.g. it cached the write request and is
going to get to it soon)? How can the OS know what the disk controller
is really doing?

Now, insert some network storage layer that runs on top of IP into
the picture and you've got some more opportunities for things to go
wrong. Now the request is passing through network stacks and possibly
firewalls, and the network may treat a lost packet as collateral
damage.

I am not saying Subversion is careless. There is nothing Subversion
can do about any of this. But these are things to consider when
building a system for high reliability purposes. The systems are
complex and the less complexity you've got the more reliability you
tend to get.