Login | Register
My pages Projects Community openCollabNet

Discussions > users > Using FSVS with multiple URL: first deployment

fsvs
Discussion topic

Back to topic list

Using FSVS with multiple URL: first deployment

Author farzy
Full name Farzad FARID
Date 2008-10-27 08:35:29 PDT
Message Hi,

As Phil Marek asked, here are my first impressions on using FSVS (1.1.16) with
2 URLs.

I'm versionning "/etc" for the moment. Setting up the first server with 2 SVN
URL was a bit tedious, because I had to decide which file/directory would go to
"base", and which would go to "local", but this problem is not related to
FSVS.

Here are the problems I have encountered for the time being:

1) Selecting the right repository the first time

The first difficulty comes from moving a file or directory from one repository to
another, if the first chosen repository was the wrong one. The best solution I
found is the procedure. Lets say for example that "/etc/posftix" was committed
in "base" (the common URL/repository), but must actually be local to each
server:

cd /etc
fsvs unversion postfix
fsvs commit -m "Moving /etc/postfix from 'base' to 'local', phase 1" -o
commit_to=base postfix
fsvs commit -m "Moving /etc/postfix from 'base' to 'local', phase 2" -o
commit_to=local postfix

This does not always work smoothly: if the subdirectories do not exist in the
2nd repository, I have to add them manually first. If for example, I want to
move "/etc/sysconfig/netw​ork-scripts" from one URL to another, before using the
previous procedure I have to execute:

fsvs add -o commit_to=local /etc/sysconfig

2) Putting /etc/fsvs in the right repository

I'm versionning "/etc", so "/etc/fsvs" MUST be handled by the "local"
URL/repository, of course :)

That's because each server sharing the common "base" URL/repository must have
it's own configuration. I don't think this is mentionned in the Master/Local
HOWTO?

3) Handling mixed-repository commits

This is the biggest problem I have, I already mentionned this in a previous
post. Here is an example:

- Lets say I modifiy files belonging to the "base" repository.
- As we already know, "/etc/fsvs" (which belongs to the "local" repository),
is always in a modified state.
- I want to commit the changes to the "base" repository without explicitely
giving the names of modified files/directories, because it is tedious (and in
somes cases there may be dozens of modified files in multiple subdirectories).
- The following command returns an error:


[root etc]# fsvs commit -m "Delete modprobe.conf_"
Committing to svn://10.10.3.24/sys​tem/preprod/front/tr​unk/etc
D... 194 modprobe.conf_
.m.. dir fsvs
.m.. dir fsvs/182f153bd948039​55c2043e6f2581d5d
.mC. 161 fsvs/182f153bd948039​55c2043e6f2581d5d/Ur​ls


An error occurred: Name does not refer to a filesystem directory (160016)
  in ci__work: editor->close_edit: Path 'fsvs' not present


As Phil explained, it is normal to have an error here, but practically it is
very tedious to handle.

In this example I just have to use: 'fsvs commit -m "Delete modprobe.conf_"
modprobe.conf_', but there are cases where '.' is modified. Therefore I can't
commit '.', otherwise it'll recursively commit the whole "/etc". I could
prevent this by adding "-N" which says "do not recurse", etc. etc.

If the commands to type become too complicated, with special cases, I know
that my customer will refuse to use fsvs :(

4) Adding a second server to the common "base"

Now that I have 1 server versionned in FSVS, with a common "base" and a
"local" repository. I now add his twin brother: another running server,
already fully installed and in production.

To configure FSVS, I give this 2nd server the common "base", and its own
"local" repository.

From them on, I had a hard time getting the 2 servers in sync! This is because
I did not install the 2nd server from scratch: I had to resolve the differences
between the 2 servers by hand.

This situation is not FSVS's fault. But I know I had to use "fsvs sync-repos",
"fsvs update", "fsvs commit", "fsvs add", "fsvs unversion", "fsvs revert"
multiple times, in multiple orders, on *both* servers..

I haven't been able yet to create a reliable checklist on how to add the 2nd
server to the FSVS versionning. I remember that, at some point, after I
manually solved many conflicting changes, "fsvs update" on the 2nd server did
not work! It did'nt update any file.

I'm still manually resolving minor conflicts on the 2nd server with "fsvs
revert". I takes some time, but it works fine. Using "fsvs status -vC | fgrep -
v '......'" was the best solution I could find to list all the changes and
determine if they are minor (just a date diffence in most cases) and can be
reverted on the 2nd server in order to be in sync with the 1st one.

So far nothing broke :) I haven't lost a single file, and installing FSVS even
helped me spot oddities, like files which should have been identical on the 2
servers, but were not.

5) Choosing the SVN directory structure

My customer and I chose the following tree:

/customer_name_N
    /project_name_M
        /generic_machine_X
            /trunk
                /etc
                /app
        /generic_machine_Y
            /trunk
                /etc
                /app
        /machines
            /machine_A
                /trunk
                    /etc
                    /app
            /machine_B
                /trunk
                    /etc
                    /app
    /project_name_M'
        /....
/customer_name_N'
    /....

The ".../generic_machine_X" contains the "base" repository for a given class
of identical servers.

The ".../machines" folder contains the "local" repository of each server.


My Suggestions:
--------------

- In mixed-repository cases, one solution would be that FSVS checks which files
belong to the repository I am committing to, and *ignores* files who don't
belong to it.

- Another solution would be to have an option to explicitely *exclude* files or
directories from a commit command.

- My prefered solution is that FSVS uses the information it already has to
determine where to commit each file. The "priority" parameter of each URL could
resolv conflicts.

- What about adding an option to "fsvs status", to display the URL alias of
each file/directory?

- Finally, in a multiple URL configuration, I find myself using the "-o
commit_to=XXXX" very often! It'd be nice to have a shortnamed command line
option for this :)

 Best regards,

--
Farzad FARID / Architecte Open Source - AssociƩ
Pragmatic Source / http://www.pragmatic-source.com
Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46

« Previous message in topic | 1 of 4 | Next message in topic »

Messages

Show all messages in topic

Using FSVS with multiple URL: first deployment farzy Farzad FARID 2008-10-27 08:35:29 PDT
     Re: Using FSVS with multiple URL: first deployment pmarek P.Marek 2008-10-28 09:26:51 PDT
     Re: Using FSVS with multiple URL: first deployment Pieter Ennes <lists at spam dot ennes dot net> Pieter Ennes <lists at spam dot ennes dot net> 2008-10-28 12:59:57 PDT
     Re: Using FSVS with multiple URL: first deployment pmarek P.Marek 2008-11-02 09:04:46 PST
Messages per page: