On Thu, 13 Sep 2012 14:20:12 +0100 "Tommaso D'Argenio" <ping...@gmail.com> wrote:
[...] > Now think at this as a web development team, so we have a web > application which doesn't need to be build or anything like that. The > dev team create a new patch on their local repository and commit it > to the remote testing branch. When they open up the browser to test > it out, they won't be able to do it because the actual file in the > remote repository it's the old one. The dev guy doesn't have the > permission to log on the remote machine and manually run a fossil > update, neither I can think of a process on the remote machine that > run the fossil update command every second. > > For instance, I have a repository with SVN on the remote machine. I > make some changes on my local repository (after the update done > locally to incorporate changes made by other), and using TortoiseSVN > I commit the changes and solve eventual conflicts with a merge. When > this is done, I open up the web app on the browser and there it is my > change. > > Am I making any sense ? Not much: a Subversion repository on a server does not have an open checkout attached to it at all. So could you please describe in more details what you're trying to achieve? So far it seems you want to somehow automagically update certain open checkout of a Fossil repository after you push new changes to a specific branch in that repository. Is this true? Then how precisely this is implemented in your Subversion setup? I, for one, cannot really imagine this. Note that a Fossil repository can have any number of open checkouts active at the same time, all of them independent from each other. This should hint you at that Fossil kind of work "backwards" here: open checkouts refer to the repository, not the other way round. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
