Farzad, thanks for this extensive list. It describes almost identically my situation and the problems I ran into, but much better and more extensively than I could have.
What crossed my mind regarding the movement of files between repositories, was to create raise/lower commands to move a file into or out of a higher repository. Pieter Farzad FARID wrote: > 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/network-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/system/preprod/front/trunk/etc > D... 194 modprobe.conf_ > .m.. dir fsvs > .m.. dir fsvs/182f153bd94803955c2043e6f2581d5d > .mC. 161 fsvs/182f153bd94803955c2043e6f2581d5d/Urls > > > 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, > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
