Login | Register
My pages Projects Community openCollabNet

Discussions > users > Re: If you do a commit if there's pending updates, updates are lost *quietly*!

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: If you do a commit if there's pending updates, updates are lost *quietly*!

Author pmarek
Full name P.Marek
Date 2011-05-12 08:32:11 PDT
Message Hello Roland!

>> But you're right; using multiple WCs with FSVS might easily make problems.
>> A repo-path should have only one _modifying_ WC.
>
> Is it hard to fix?
...
> I've C experience, but only limited time - worth to try?
Well, yes and no.

You've described the unfortunate case where no prior information was kept - starting
afresh without local file lists, from revision 0 on.

Getting complete mixed working copies working is much work; I'm not sure how much I
already managed to put into FSVS.

I think that for single URLs it should be fairly complete; and subversion should throw
an error if we get conflicts on commit.

So, basically, it should work, provided that you don't start with an empty WC - that
means doing an "fsvs update" or "fsvs sync-repos" _before_ working with a WC, eg. simply
after defining the URLs.


You could put some code into FSVS that simply makes an update before committing; that
might help a bit.


> We're planning to use fsvs to keep our cluster nodes in sync. Fsvs
> should be as transparent for the administrators as possible, if they
> can make changes in only one working set, I have to fight with them
> till my last blood. :)

>> If you really want to handle the same repository-directory, always use "fsvs update"
>> before committing.
>
> Sounds like a reasonable workaround if proper fix isn't possible.
>
 > (IMHO it's a critical bug for everyone who uses fsvs to keep cluster
> nodes in sync, because a node can outdate without any warning and that
> can cause annoying hard-to-find problems in the services of the load
> balanced cluster. Maybe you should put a message about it under "KNOWN
> BUGS" or "LIMITATIONS" section in the fsvs man page.)
Well, IIRC it shouldn't be that simple to trigger.

Apart from the hint above, there's always a simple workaround; "fsvs sync-repos" will
fetch a completely fresh contents-list from the repository, and then show changes as
usual.
So the recovery might simply be "fsvs sync-repos" and "fsvs revert / -R" (if you're that
brave ;-)


The major problem I encountered (and which caused me to pause this project) was the
complexity involved with more than one URL and mixed revision working copies.

I still plan to re-write FSVS, for true multi-URL operations ... sadly most of my steam
was taken by discovering the "bup" project (backup into git repositories), because
that's what the rewrite should have done (using git as backend).


What I'm trying to say with this is: Especially for cluster configuration it might make
sense to have more than one URL - eg. one for the common data, and one per node. Sadly
there are a few holes in FSVS for this use-case - having to run "fsvs update" before
committing is one of them.


To wrap this all up - AFAIK FSVS is already used to sync contents between two or more
nodes, so it should work fine for single-URL, well-initialized usage, apart from the
leak when starting afresh; but please tell me if you discover other evidence ;-)



Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: If you do a commit if there's pending updates, updates are lost *quietly*!

Author Pallai Roland <pallair at magex dot hu>
Full name Pallai Roland <pallair at magex dot hu>
Date 2011-05-12 08:07:06 PDT
Message Hi Philipp,

2011/5/12 P.Marek <philipp at marek dot priv dot at>:
>> I think I found a bug in fsvs 1.2.3, please confirm or confute it:
>>
>> $ svnadmin create ~/svnr/repo1
>>
>> $ mkdir etc{1,2}
>> $ ( cd etc1 && fsvs url
>> name:repo1,prio:10,t​arget:HEAD,ro:0,file​:///root/svnr/repo1 )
>> $ ( cd etc2 && fsvs url
>> name:repo1,prio:10,t​arget:HEAD,ro:0,file​:///root/svnr/repo1 )
>>
>> etc1$ echo data >testfile1 && fsvs ci -m 1st
>> N...         5   testfile1
>> committed revision    1 on 2011-05-11T16:56:36.772102Z as root
>>
>> etc2$ fsvs rem
>> N...         0   testfile1
>> ..C.       dir   .
>> Remote-status against revision        1.
> Try "fsvs update" here, that should give you the file.
>
> But you're right; using multiple WCs with FSVS might easily make problems.
> A repo-path should have only one _modifying_ WC.

Is it hard to fix?

We're planning to use fsvs to keep our cluster nodes in sync. Fsvs
should be as transparent for the administrators as possible, if they
can make changes in only one working set, I have to fight with them
till my last blood. :)
I've C experience, but only limited time - worth to try?


> If you really want to handle the same repository-directory, always use "fsvs update"
> before committing.

Sounds like a reasonable workaround if proper fix isn't possible.


(IMHO it's a critical bug for everyone who uses fsvs to keep cluster
nodes in sync, because a node can outdate without any warning and that
can cause annoying hard-to-find problems in the services of the load
balanced cluster. Maybe you should put a message about it under "KNOWN
BUGS" or "LIMITATIONS" section in the fsvs man page.)

Re: If you do a commit if there's pending updates, updates are lost *quietly*!

Author pmarek
Full name P.Marek
Date 2011-05-12 04:05:30 PDT
Message Hello Roland!

> I think I found a bug in fsvs 1.2.3, please confirm or confute it:
>
> $ svnadmin create ~/svnr/repo1
>
> $ mkdir etc{1,2}
> $ ( cd etc1 && fsvs url
> name:repo1,prio:10,t​arget:HEAD,ro:0,file​:///root/svnr/repo1 )
> $ ( cd etc2 && fsvs url
> name:repo1,prio:10,t​arget:HEAD,ro:0,file​:///root/svnr/repo1 )
>
> etc1$ echo data >testfile1 && fsvs ci -m 1st
> N... 5 testfile1
> committed revision 1 on 2011-05-11T16:56:36.772102Z as root
>
> etc2$ fsvs rem
> N... 0 testfile1
> ..C. dir .
> Remote-status against revision 1.
Try "fsvs update" here, that should give you the file.

But you're right; using multiple WCs with FSVS might easily make problems.
A repo-path should have only one _modifying_ WC.

If you really want to handle the same repository-directory, always use "fsvs update"
before committing.


Depending on your use-case you could commit to different repository paths, and just
overlay them - see http://fsvs.tigris.o​rg/purpose.html or the documentation for more
information.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

If you do a commit if there's pending updates, updates are lost *quietly*!

Author Pallai Roland <pallair at magex dot hu>
Full name Pallai Roland <pallair at magex dot hu>
Date 2011-05-11 10:22:47 PDT
Message Hi,


I think I found a bug in fsvs 1.2.3, please confirm or confute it:

$ svnadmin create ~/svnr/repo1

$ mkdir etc{1,2}
$ ( cd etc1 && fsvs url
name:repo1,prio:10,t​arget:HEAD,ro:0,file​:///root/svnr/repo1 )
$ ( cd etc2 && fsvs url
name:repo1,prio:10,t​arget:HEAD,ro:0,file​:///root/svnr/repo1 )

etc1$ echo data >testfile1 && fsvs ci -m 1st
N... 5 testfile1
committed revision 1 on 2011-05-11T16:56:36.772102Z as root

etc2$ fsvs rem
N... 0 testfile1
..C. dir .
Remote-status against revision 1.
etc2$ echo data >testfile2 && fsvs ci -m 2nd
N... 5 - testfile2
committed revision 2 on 2011-05-11T16:58:13.221447Z as root
etc2$ ls
testfile2
etc2$ fsvs rem
Remote-status against revision 2.
* hey, where's testfile1? *

I tried everything to get testfile1 into etc2 with fsvs, but I can't,
fsvs in etc2 totally ignores if testfile1 exists in the repository.
This problem affects every changes, not only newly created files.

$ svn ls -v file:///root/svnr/repo1/
      2 root May 11 18:58 ./
      1 root 5 May 11 18:56 testfile1
      2 root 5 May 11 18:58 testfile2


--
 Roland Pallai
Messages per page: