[fossil-users] Post-commit hook
I mange my web site using Fossil. I have a repository on the server as well as a working copy there. Any time I make changes and commit I'd like to notify the remote working directory (which is also set as Apache's DocumentRoot) to update to the latest version. Thus the question: is it possible to have some kind of post-commit hook on the repository to automate the process? This has probably been asked already, but I failed to find the answer. Thanks. -- Good luck, Pasha Bastov ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Post-commit hook
I mange my web site using Fossil. I have a repository on the server as well as a working copy there. I do the same. But rather than rely on a post-commit hook, I rely on a bash script which: pushes my changes to the server logs in to the server and 'updates' the site (the DocumentRoot) runs any other fix up stuff necessary Best regards, Ron -- For privacy, my GPG key signature is: AD29415D signature.asc Description: This is a digitally signed message part. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Post-commit hook
Thanks Richard, the only kind of background processes I'm familiar with on Windows is windows services. But I'm not sure it's what you need. On Mon, Jan 3, 2011 at 5:58 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Jan 3, 2011 at 6:43 AM, Pasha pbas...@gmail.com wrote: I mange my web site using Fossil. I have a repository on the server as well as a working copy there. Any time I make changes and commit I'd like to notify the remote working directory (which is also set as Apache's DocumentRoot) to update to the latest version. Thus the question: is it possible to have some kind of post-commit hook on the repository to automate the process? This has probably been asked already, but I failed to find the answer. There is a branch in the Fossil source tree to do this, but I did not accept that branch into the trunk. I've got a plan for a better way to do various hooks, but in order for it to work cross-platform, I need code that will start a background process on windows. By background process, I mean a process that will continue running even after its parent process exits or is killed. If any windows experts out there can explain to me how to do that, or provide sample code, that will expedite getting the hook logic into the Fossil trunk. Thanks. -- Good luck, Pasha Bastov ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Why not? © Pasha Bastov ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Errors during compile in Windows 7 x64
Windows users - please try this on your machines and let me know if you have problems. Thanks everyone for your help in fixing this problem. Makefile.mingw Works for me in Win7+MSYS+MINGW. I think it will be very difficult to make a VS2008 or VS2010 solution that will do the build in the IDE. I have worked with at least one project that builds with a makefile project in the IDE - http://ta-lib.org/ - the ta_libc project is done with NMake. That's about the extent of my ability to contribute on this. Sorry. BTW since makefile.win32 is now removed from the repository, the build wiki needs to be updated to remove references to it. RW Ron Wilson, Engineering Project Lead (o) 434.455.6453, (m) 434.851.1612, www.harris.com HARRIS CORPORATION | RF Communications Division assuredcommunicationsT ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Has anyone tried sharing a repo via DropBox?
Hello, fossilers! Some of my fossil repos are not on the web, but instead in my DropBox (a file backup/sync service: http://getdropbox.com). i'm wondering if another Dropbox user out there has tried sharing a fossil repo with other developers via dropbox-shared folders. If so, were there any notable problems? Obviously, if either commit while a sync is taking place it could cause Dropbox to produce two copies (before/after collision), but dropbox sync is pretty fast, and doesn't take much more time then an http/fossil-server-based sync. i have used fossil-in-a-dropbox for months, but have never tried sharing such a repo with dropbox shared folders. If one of you is curious and sends me your dropbox user name i can set up a folder for us to try this out. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Has anyone tried sharing a repo via DropBox?
On Mon, Jan 3, 2011 at 8:08 PM, Michael Barrow mich...@barrow.me wrote: This doesn't sound like a good idea at all. Yes the sync is pretty quick under normal circumstances, but that could easily go awry. Who would fix the two copies of the repo when there is a simultaneous commit by two parties? That's what dropbox does if it finds a conflict (same file changed on 2+ machines between syncs). It creates a file named Basename (conflict - hostnameOfConflictedFile).ext (or something similar). It has happened to me a couple times when i've edited an ODT file on two machines which subsequently synced. Normally sync happens immediately, but if the network is not reachable or dropbox has been turned off (or not turned on) then syncing is delayed until the next time the dropbox back-end can be reached. Obviously there would be the glaring problem with potential conflicts, but dropbox behaves intelligently here and doesn't hose one copy or the other. It also, however, doesn't, loudly complain, so you don't see the conflicted files unless you look for them. For a small project with 1-2 devs who work in different timezones, it might be reasonable. And read-only access should never be a problem. The main difference for people watching the repo would be that they never need to fossil pull because dropbox copies over the changes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
