[fossil-users] [newbie] Can't get started
Hello This is the first time I'm trying Fossil and I'm using the Windows version (d8221b9863 2011-05-12). I will be the only user, and the repository will be located on the same Windows host where the repository is saved. There are a few of questions to which I found no answer in the wiki: 1. Should the repository be located at the very top of the directory tree where files will be added and commited? For instance, if the files I'll be adding/committing live below C:\, should the repository be C:\myrepo, or is it OK to locate it anywhere on the hard drive, eg. D:\whatever\lmyrepo? 2. Is it OK to have spaces in the path leading to the repo and the files, eg. C:\This is a directory\myrepo, and D:\This is where my files are\some file.txt? 3. Is it possible _not_ to be prompted for a comment when committing a file? I'd just like to type fossil commit, and be done with it. 4. Is it possible to open the repository in a DOS box (C:\fossil.exe open c:\myrepo), and add/commit from a Windows application such as a text editor? When I tried this, I got this error: C:\fossil.exe: not within an open checkout I guess all the commands should be issued within the DOS box. Thank you. ___ 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] [newbie] Can't get started
On May 25, 2011, at 13:29 , Gilles wrote: 1. Should the repository be located at the very top of the directory tree where files will be added and commited? No. I'd keep it somewhere else. 2. Is it OK to have spaces in the path leading to the repo and the files, eg. C:\This is a directory\myrepo, and D:\This is where my files are\some file.txt? Yes, but it's mighty inconvenient. But Fossil does not create any problems with that. 3. Is it possible _not_ to be prompted for a comment when committing a file? I'd just like to type fossil commit, and be done with it. It's a bad idea. But I guess that adding something like -m ' ' to the commit command should do the trick. 4. Is it possible to open the repository in a DOS box (C:\fossil.exe open c:\myrepo), and add/commit from a Windows application such as a text editor? When I tried this, I got this error: C:\fossil.exe: not within an open checkout Because you first need to open a repo, look into fossil help open. I guess all the commands should be issued within the DOS box. Well, anyways you need something that's able to issue the commands. You can always try one of the GUI programs. Kind regards, Remigiusz Modrzejewski ___ 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] [newbie] Can't get started
On 5/25/2011 7:29 AM, Gilles wrote: 1. Should the repository be located at the very top of the directory tree where files will be added and commited? For instance, if the files I'll be adding/committing live below C:\, should the repository be C:\myrepo, or is it OK to locate it anywhere on the hard drive, eg. D:\whatever\lmyrepo? It doesn't matter what drive or folder you put the repo database in, except that you don't want to put it inside your working copy. E.g., if your project is in c:\myproj, the only place your repo shouldn't be is in c:\myproj. Also, you want to avoid storing the repo on a network drive most of the time. 2. Is it OK to have spaces in the path leading to the repo and the files, eg. C:\This is a directory\myrepo, and D:\This is where my files are\some file.txt? Yeah, it's cool. 3. Is it possible _not_ to be prompted for a comment when committing a file? I'd just like to type fossil commit, and be done with it. Every commit has to have a comment, but you can specify it on the command line like this: fossil commit -m my comment 4. Is it possible to open the repository in a DOS box (C:\fossil.exe open c:\myrepo), and add/commit from a Windows application such as a text editor? When I tried this, I got this error: C:\fossil.exe: not within an open checkout I don't really understand what you're trying to do there. At the very beginning of a project, do something like this: fossil new c:\fossil-repos\myproj.fossil cd c:\myproj fossil open c:\fossil-repos\myproj.fossil There is now a _FOSSIL_ file in c:\myproj and nothing else unless you had some files there already. (And it's ok if you did!) You won't need to do the above steps again until you start a new project (or a few other things, but relax for now). 'fossil open' is not a daily activity. Now, say you have some work you want to commit. Assuming you're still in c:\myproj... fossil add . to add all the not-yet-checked-in files here to your commit or... fossil add some-file some-other-file Then... fossil status Make sure that the output matches the branch you thought you were on and shows the files you thought you changed. (Not that fossil will ever be wrong about this, but that you might be.) fossil commit -m Lovely work. Wahoo! So I have no idea what you mean about adding or committing from a test editor. If you have a text editor that will give you a command prompt inside it, then I would expect fossil to work fine so long as you first cd to the project directory. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] [newbie] Can't get started
On Wed, 25 May 2011 13:29:58 +0200, Gilles wrote: Hello This is the first time I'm trying Fossil and I'm using the Windows version (d8221b9863 2011-05-12). I will be the only user, and the repository will be located on the same Windows host where the repository is saved. There are a few of questions to which I found no answer in the wiki: 1. Should the repository be located at the very top of the directory tree where files will be added and commited? For instance, if the files I'll be adding/committing live below C:\, should the repository be C:\myrepo, or is it OK to locate it anywhere on the hard drive, eg. D:\whatever\lmyrepo? The repository should not be in the directory were you work! e.g mkdir c:\src\myproject fossil new c:\src\gilles.fossil cd c:\src\myproject fossil open ../gilles.fossil 2. Is it OK to have spaces in the path leading to the repo and the files, eg. C:\This is a directory\myrepo, and D:\This is where my files are\some file.txt? The directories leading up to your repository or your check-out it doesn't matter much But the file names and directories in you repo/checkout it is not recommended but possible. You need to add around the name. You might get into trouble when issuing fossil add * 3. Is it possible _not_ to be prompted for a comment when committing a file? I'd just like to type fossil commit, and be done with it. fossil commit -m nocomment not recommend though 4. Is it possible to open the repository in a DOS box (C:\fossil.exe open c:\myrepo), and add/commit from a Windows application such as a text editor? When I tried this, I got this error: C:\fossil.exe: not within an open checkout The editor you used wasn't started in that directory. open a dos box and cd into c:\src\myproject start your editor I guess all the commands should be issued within the DOS box. Depends if I would be using the editor vim I could issue :cd c:\myproject (make sure I'm in the checkout directory) :!c:\fossil.exe commit -m Nocomment Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Rene ___ 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] [newbie] Can't get started
On Wed, May 25, 2011 at 7:29 AM, Gilles gilles.gana...@free.fr wrote: Hello This is the first time I'm trying Fossil and I'm using the Windows version (d8221b9863 2011-05-12). I will be the only user, and the repository will be located on the same Windows host where the repository is saved. There are a few of questions to which I found no answer in the wiki: 1. Should the repository be located at the very top of the directory tree where files will be added and commited? For instance, if the files I'll be adding/committing live below C:\, should the repository be C:\myrepo, or is it OK to locate it anywhere on the hard drive, eg. D:\whatever\lmyrepo? The repo can be anywhere on your hard-drive. I tend to create a single folder some place and put all of my repos there. (I typically have dozens on any one machine.) That helps to keep things organized, but is certainly not required. 2. Is it OK to have spaces in the path leading to the repo and the files, eg. C:\This is a directory\myrepo, and D:\This is where my files are\some file.txt? Yes. 3. Is it possible _not_ to be prompted for a comment when committing a file? I'd just like to type fossil commit, and be done with it. Use the -m command-line option to commit to enter your comment on the command-line. Fossil requires a comment of some kind. You *should* enter a reasonable comment on every commit. You'll thank yourself years later when you are going back trying to figure out what you did. When I first started writing SQLite back in 2000, I was in the habit of making every check-in comment a smiley. See http://localhost:591/sqlite/timeline?c=2000-01-01 for example. That was a bad idea. Do not repeat my mistake. 4. Is it possible to open the repository in a DOS box (C:\fossil.exe open c:\myrepo), and add/commit from a Windows application such as a text editor? When I tried this, I got this error: C:\fossil.exe: not within an open checkout The working directory of the process must be in the checkout. A unix program will normally preserve your working directory. But windows is different. If you want the command to work, you'll have to find a way to make your working directory fall somewhere within your checkout. I guess all the commands should be issued within the DOS box. Thank you. ___ 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
Re: [fossil-users] [newbie] Can't get started
On Wed, May 25, 2011 at 2:28 PM, Gilles gilles.gana...@free.fr wrote: file to a repository after opening it in a DOS box, but I get the following error when I try to commit: = C:/SOMEDIR/myfile.txt contains CR/NL line endings; commit anyhow (yes/no/all)? C:\fossil.exe: Abandoning commit due to CR+NL line endings in C:/SOMEDIR/myfile.txt = That's not an error, but a warning. Simply tap aENTER and ignore it. You're on Windows, so files will tend to use CRNL endings. On Unix systems CRNL combinations are normally undesireable, and can in fact break certain file types (e.g. shell scripts, especially if the shebang line ends with a \r). Google didn't return any document about that error: Is there a way to provide Fossil with an answer to that question, so as not to be prompted? Google knows everything except perhaps what i have in my fridge (and he can guess that, given my personality profile). It's mostly a matter for formulating the question (which of course isn't always obvious when one isn't familiar with the topic): http://en.wikipedia.org/wiki/Newline -- - 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] [newbie] Can't get started
On Wed, 25 May 2011 09:26:25 -0400, Tomek Kott tkott.s...@gmail.com wrote: You can specify whether to ignore the line endings (they're different for win vs. linux vs. osx, and windows does things oddly...I guess). Open up the ui (fossil ui in an open repository) and then go to the admin, then settings. Find the crnl-glob setting, and set it to *. This will ignore all windows CR/NL bad line endings. I don't know how horribly horrible this is for others, but I have that as a default setting on my computer (win7). Thanks, that did it. ___ 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] [newbie] Can't get started
On Wed, 25 May 2011 13:29:58 +0200, Gilles gilles.gana...@free.fr wrote: This is the first time I'm trying Fossil and I'm using the Windows version (d8221b9863 2011-05-12). I noticed something else: If my work directory, ie. where files from the repository are checked out, is on the C partition, Fossil won't let me add a file that is located on another partition. For instance, with the repository file at the root of C:\ (so I can add any file below that, even in sub-directories), trying to add D:\test.txt triggers the error message: C:\fossil.exe: not within an open checkout. Is there a work-around, or does a repository only accept files located on the drive of work directory, and anywhere below it in the tree? Thank you. ___ 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] [newbie] Can't get started
On Wed, May 25, 2011 at 4:06 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, May 25, 2011 at 3:59 PM, Gilles gilles.gana...@free.fr wrote: I noticed something else: If my work directory, ie. where files from the repository are checked out, is on the C partition, Fossil won't let me add a file that is located on another partition. Fossil requires all files in a given repo to share a common parent directory. BTW: that's not just fossil. i don't know of any SCM which allows one to add arbitrary paths to an arbitrary repository. -- - 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] [newbie] Can't get started
On Wed, 25 May 2011 16:06:42 +0200, Stephan Beal sgb...@googlemail.com wrote: Fossil requires all files in a given repo to share a common parent directory. BTW: that's not just fossil. i don't know of any SCM which allows one to add arbitrary paths to an arbitrary repository. Thanks for the confirmation. ___ 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] [newbie] Can't get started
On 5/25/2011 9:59 AM, Gilles wrote: For instance, with the repository file at the root of C:\ (so I can add any file below that, even in sub-directories), trying to add D:\test.txt triggers the error message: C:\fossil.exe: not within an open checkout. This is correct behavior. If you took your repo and opened it on another computer, either in the c:\ root or in a folder, fossil could restore all the files in exactly the same relation to each other as you had them. They might have a different root or be on a completely different drive, but if you had a file in \foo that referred to ..\bar\otherfile, the reference would still work. But what if you were allowed to add d:\test.txt? What's fossil supposed to do when you open that repo again somewhere else? I don't have a D: drive. Lots of computers have a DVD drive under D:. And even if I have a D: drive, what if I open your repo twice in two different folders on my system? (E.g., assuming it's software, to keep one behaving normally and make my weird changes in the other copy to compare.) So, yeah, all your repo files have to have a common root. It's by design and can't be worked around except by moving files into a common root. (And check out http://en.wikipedia.org/wiki/NTFS_junction_point) And you should really think about your entire-c-drive-is-my-working-copy thing. Maybe it makes sense for your use case, but it's at least a very unusual use of fossil. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] [newbie] Can't get started
On Wed, 25 May 2011 10:30:37 -0400, Joshua Paine jos...@letterblock.com wrote: This is correct behavior. Yes, makes perfect sense. And you should really think about your entire-c-drive-is-my-working-copy thing. Maybe it makes sense for your use case, but it's at least a very unusual use of fossil. I know it's unusual, but I only wanted a tiny SCM because the Windows editor doesn't support versioning internally. It's just so I can try things on small scripts and be able to cancel if they didn't work. ___ 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] [newbie] Can't get started
On Wed, May 25, 2011 at 4:34 PM, Gilles gilles.gana...@free.fr wrote: I know it's unusual Just don't do: fossil add . and if you do try it, just remember that you were warned. -- - 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] [newbie] Can't get started
On Wed, 25 May 2011 16:37:26 +0200, Stephan Beal sgb...@googlemail.com wrote: Just don't do: fossil add . and if you do try it, just remember that you were warned. I will promptly forget what I just read ;-) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil usage in root directory (was Re: [newbie] Can't get started)
[thread intentionally broken] * Joshua Paine jos...@letterblock.com [20110525 16:21]: On 5/25/2011 9:59 AM, Gilles wrote: For instance, with the repository file at the root of C:\ (so I can add any file below that, even in sub-directories), trying to add D:\test.txt triggers the error message: C:\fossil.exe: not within an open checkout. [...] So, yeah, all your repo files have to have a common root. It's by design and can't be worked around except by moving files into a common root. (And check out http://en.wikipedia.org/wiki/NTFS_junction_point) And you should really think about your entire-c-drive-is-my-working-copy thing. Maybe it makes sense for your use case, but it's at least a very unusual use of fossil. I beg to differ. 2 users is a lower bound for this use case. As stated in http://fossil-scm.org/index.html/tktview?name=ee97701f4c , this severely limits the usability of fossil for system configuration management: it's not possible to just set ignore-glob='*' and add versioned configuration files as needed. It's a pity, because fossil's all-in-one approach and its statically compiled distribution make it an excellent candidate for this use case. I understand the reason for the current behaviour, but I believe the a.m. ticket is a bug (which I don't know how to fix). qvb -- pica ___ 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] fossil usage in root directory (was Re: [newbie] Can't get started)
On Wed, May 25, 2011 at 4:42 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: As stated in http://fossil-scm.org/index.html/tktview?name=ee97701f4c , this severely limits the usability of fossil for system configuration management: it's not possible to just set ignore-glob='*' and add versioned configuration files as needed. It's a pity, because fossil's all-in-one approach and its statically compiled distribution make it an excellent candidate for this use case. Yes, but fossil's primary purpose is a source control system, not a 100% general-purpose SCM (or maybe i'm assuming too much there), and no developer puts all his source code under the root directory (possibly another incorrect assumption). On Unix systems, the vast majority of volatile/mutable config data lives under /etc or a user's home dir, and one can of course create a fossil repo/checkout under /etc. But that brings us to another reason NOT to use fossil from your root dir for versioning arbitrary system-level config data: fossil does not support full persistence of access rights. It supports the +x bit, but Richard only added that (AFAIR) after many people bemoaned having to chmod +x their configure scripts after each checkout. Some files under, e.g., /etc require specific rights. e.g. Linux does not like it if /etc/shadow is world-readable (from what i remember, anyway) and ssh doesn't like for some files to be world-readable. -- - 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] fossil usage in root directory (was Re: [newbie] Can't get started)
* Stephan Beal sgb...@googlemail.com [20110525 16:52]: On Wed, May 25, 2011 at 4:42 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: As stated in http://fossil-scm.org/index.html/tktview?name=ee97701f4c , this severely limits the usability of fossil for system configuration management: it's not possible to just set ignore-glob='*' and add versioned configuration files as needed. It's a pity, because fossil's all-in-one approach and its statically compiled distribution make it an excellent candidate for this use case. Yes, but fossil's primary purpose is a source control system, not a 100% general-purpose SCM (or maybe i'm assuming too much there), and no developer puts all his source code under the root directory (possibly another incorrect assumption). On Unix systems, the vast majority of volatile/mutable config data lives under /etc or a user's home dir, and one can of course create a fossil repo/checkout under /etc. But that brings us to another reason NOT to use fossil from your root dir for versioning arbitrary system-level config data: fossil does not support full persistence of access rights. It supports the +x bit, but Richard only added that (AFAIR) after many people bemoaned having to chmod +x their configure scripts after each checkout. Some files under, e.g., /etc require specific rights. e.g. Linux does not like it if /etc/shadow is world-readable (from what i remember, anyway) and ssh doesn't like for some files to be world-readable. Bummer, I incorrectly assumed that fossil tracked all permissions. It doesn't seem that doing so would be too hard though: http://fossil-scm.org/index.html/doc/tip/www/fileformat.wiki The optional 3rd argument defines any special access permissions associated with the file. The only special code currently defined is x which means that the file is executable. All files are always readable and writable. This can be expressed by w permission if desired but is optional. The file format might be extended with new permission letters in the future. Richard, would you consider such a feature request? tks -- pica ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Non-synchronized Fossil repositories for same project, can it be done?
A commercial company is interested in productizing one of my open source apps. The thought is to keep all existing pieces as open, but to change the app's name, and to add in various proprietary code designed to tap into their own services. Even so, development on the open code will continue, and occasionally changes will be pulled from the open codebase into the closed one. I'd like to stick with using Fossil for both projects, but I'm wondering how to manage this case where these two repositories aren't truly in sync. I'd like to keep closed code completely outside of any open repositories to avoid accidentally tainting open code, so private branches wouldn't seem to be an option. My current thoughts are to clone the open project's repository, deliver that to the company as something they can host on their server. Any open development happens in the open repository, then when I want to merge in changes, I cd to the closed project and run: fossil pull --once http://open.project.url/ My guess is that this would just pull in open changes and won't try to push closed code (I.e. just one side of sync.) Is this going to complain about anything, though? I.e. will it complain if the repositories aren't exact copies before the pull? Also, ideally the changes won't introduce conflicts, since the closed code will be in an entirely separate package. There will be changes in at least one file in the closed branch, though, the AndroidManifest.xml which changes the app name and such. Will Fossil be OK with merging changes that don't cause conflicts, even if the repositories aren't strictly in sync? I hope I can use Fossil in this scenario, as it would vastly ease the pain of trying to keep the proprietary version in sync with the open version. ___ 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] fossil usage in root directory (was Re: [newbie] Can't get started)
On Wed, May 25, 2011 at 5:10 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Bummer, I incorrectly assumed that fossil tracked all permissions. System-level config files often need to belong to a specific user and/or group. So fossil would also have to track user names, and there is no guaranty that user 'stephan' on host1 is actually the same user as 'stephan' on host2 (though they tend to be the same person on my systems ;). Philosophically, i don't think that problem can be solved generically. Even if fossil did support storing/restoring the whole permissions (with user/group names/IDs), it literally couldn't work for anyone but the root user: Unix systems won't let a user's process chown a file to a different user. [stephan@cheyenne:~/Documents/Consol/allez/www]$ chown root index.php chown: changing ownership of `index.php': Operation not permitted and one can only chgrp with groups he's a member of: [stephan@cheyenne:~/Documents/Consol/allez/www]$ chgrp daemon index.php chgrp: changing group of `index.php': Operation not permitted And what to do on files imported into fossil from Windows and checked out on Unix systems? == Huge Can of Worms -- - 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] Non-synchronized Fossil repositories for same project, can it be done?
On Wed, May 25, 2011 at 11:26 AM, Nolan Darilek no...@thewordnerd.infowrote: A commercial company is interested in productizing one of my open source apps. The thought is to keep all existing pieces as open, but to change the app's name, and to add in various proprietary code designed to tap into their own services. Even so, development on the open code will continue, and occasionally changes will be pulled from the open codebase into the closed one. I'd like to stick with using Fossil for both projects, but I'm wondering how to manage this case where these two repositories aren't truly in sync. I'd like to keep closed code completely outside of any open repositories to avoid accidentally tainting open code, so private branches wouldn't seem to be an option. My current thoughts are to clone the open project's repository, deliver that to the company as something they can host on their server. Any open development happens in the open repository, then when I want to merge in changes, I cd to the closed project and run: fossil pull --once http://open.project.url/ My guess is that this would just pull in open changes and won't try to push closed code (I.e. just one side of sync.) Is this going to complain about anything, though? I.e. will it complain if the repositories aren't exact copies before the pull? Yes. The above will just pull in changes from the open version of the project and will make no attempt to push local (proprietary) changes back to the open project. Exactly what you want. For added safety, make sure that the close-source developers do NOT have a login on the open-source project that permits push. Then they won't be able to push proprietary code out to the open-source server even by mistake! Something like this has been going on with SQLite for years. (Remember: The purpose of Fossil is to provide configuration management for SQLite - all other uses are just gravy.) SQLite has three self-synchronizing public Fossil repos in Dallas, New York, and San Francisco. But server logs tell me that there are about 2 dozen other private repos around the world that regularly pull from the public repositories. None of those other 2 dozen repositories have check-in permission (I don't even know who they are) so they cannot push even if they wanted to. But presumably, some of them have their own branches with their own proprietary changes. Also, ideally the changes won't introduce conflicts, since the closed code will be in an entirely separate package. There will be changes in at least one file in the closed branch, though, the AndroidManifest.xml which changes the app name and such. Will Fossil be OK with merging changes that don't cause conflicts, even if the repositories aren't strictly in sync? I hope I can use Fossil in this scenario, as it would vastly ease the pain of trying to keep the proprietary version in sync with the open version. ___ 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
Re: [fossil-users] Non-synchronized Fossil repositories for same project, can it be done?
On Wed, May 25, 2011 at 12:27 PM, Nolan Darilek no...@thewordnerd.infowrote: Oh excellent, glad to know this is possible. You note that there are logs of others doing this for SQLite. How do you know? Right. I can see the periodic HTTP requests for pulls. You can do this automatically with a crontab entry. -- 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
Re: [fossil-users] fossil usage in root directory (was Re: [newbie] Can't get started)
On Wed, May 25, 2011 at 10:35 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, May 25, 2011 at 5:10 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Bummer, I incorrectly assumed that fossil tracked all permissions. System-level config files often need to belong to a specific user and/or group. So fossil would also have to track user names, and there is no guaranty that user 'stephan' on host1 is actually the same user as 'stephan' on host2 (though they tend to be the same person on my systems ;). Philosophically, i don't think that problem can be solved generically. Backup systems have to deal with these things. AFAIK, they usually store users and groups by ID, not by name. Even if fossil did support storing/restoring the whole permissions (with user/group names/IDs), it literally couldn't work for anyone but the root user: Unix systems won't let a user's process chown a file to a different user. Etckeeper does what Joan wants, using Git, Bzr, DARCS, or Mercurial: http://kitenet.net/~joey/code/etckeeper/ Of course you run this as root as you would with any other backup tool. Can't restore a backup, in general, unless you're root. [stephan@cheyenne:~/Documents/Consol/allez/www]$ chown root index.php chown: changing ownership of `index.php': Operation not permitted and one can only chgrp with groups he's a member of: [stephan@cheyenne:~/Documents/Consol/allez/www]$ chgrp daemon index.php chgrp: changing group of `index.php': Operation not permitted And what to do on files imported into fossil from Windows and checked out on Unix systems? == Huge Can of Worms A lot of people seem to be able to use etckeeper just fine. Bill ___ 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] fossil usage in root directory (was Re: [newbie] Can't get started)
On Wed, May 25, 2011 at 7:09 PM, Bill Burdick bill.burd...@gmail.comwrote: Backup systems have to deal with these things. AFAIK, they usually store users and groups by ID, not by name. Which is portable across one system, but not arbitrary systems. Backups are played back onto the same system or a replacement. tar handles it like (for unpacking): - non-root users cause unpacked files to belong to that user - use root will keep the user mappings (i'm fairly sure, but not certain, that it uses names, as opposed to IDs). i have no idea what it does when root unpacks a file and it cannot find the id (probably assigns ownership to root). Etckeeper does what Joan wants, using Git, Bzr, DARCS, or Mercurial: http://kitenet.net/~joey/code/etckeeper/ Of course you run this as root as you would with any other backup tool. Can't restore a backup, in general, unless you're root. ... A lot of people seem to be able to use etckeeper just fine. i'm not aware of etckeeper, but judging by the name its a tool specialized for the job, whereas fossil alone tends to specialize on the needs of source trees (or, specifically, the needs of sqlite3's source tree, as Richard pointed 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] fossil usage in root directory (was Re: [newbie] Can't get started)
On Wed, May 25, 2011 at 12:21 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, May 25, 2011 at 7:09 PM, Bill Burdick bill.burd...@gmail.comwrote: Backup systems have to deal with these things. AFAIK, they usually store users and groups by ID, not by name. Which is portable across one system, but not arbitrary systems. Backups are played back onto the same system or a replacement. Joan wants to use Fossil for system configuration management, so it's not supposed to be portable across arbitrary systems. tar handles it like (for unpacking): - non-root users cause unpacked files to belong to that user - use root will keep the user mappings (i'm fairly sure, but not certain, that it uses names, as opposed to IDs). i have no idea what it does when root unpacks a file and it cannot find the id (probably assigns ownership to root). Tar file IDs are numbers, not names (just like in UNIX/Linux), so it doesn't verify ids when run as root, it just creates the files with the ids in the archive. Etckeeper does what Joan wants, using Git, Bzr, DARCS, or Mercurial: http://kitenet.net/~joey/code/etckeeper/ Of course you run this as root as you would with any other backup tool. Can't restore a backup, in general, unless you're root. ... A lot of people seem to be able to use etckeeper just fine. i'm not aware of etckeeper, but judging by the name its a tool specialized for the job, whereas fossil alone tends to specialize on the needs of source trees (or, specifically, the needs of sqlite3's source tree, as Richard pointed out). Etckeeper is a specialized tool that uses DVCSes for versioning. It's OK that Fossil can't support everything needed for this, but I don't think it's unreasonable for Joan to ask whether Fossil can be used for it -- every major DVCS can, except for Fossil. Bill ___ 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] Non-synchronized Fossil repositories for same project, can it be done?
Nolan, That should work just fine. I would put the closed-source variant in a separate branch, so they can pull your changes and either merge wholesale or cherrypick at will. Ge' On Wed, 25 May 2011, Nolan Darilek wrote: A commercial company is interested in productizing one of my open source apps. The thought is to keep all existing pieces as open, but to change the app's name, and to add in various proprietary code designed to tap into their own services. Even so, development on the open code will continue, and occasionally changes will be pulled from the open codebase into the closed one. I'd like to stick with using Fossil for both projects, but I'm wondering how to manage this case where these two repositories aren't truly in sync. I'd like to keep closed code completely outside of any open repositories to avoid accidentally tainting open code, so private branches wouldn't seem to be an option. My current thoughts are to clone the open project's repository, deliver that to the company as something they can host on their server. Any open development happens in the open repository, then when I want to merge in changes, I cd to the closed project and run: fossil pull --once http://open.project.url/ My guess is that this would just pull in open changes and won't try to push closed code (I.e. just one side of sync.) Is this going to complain about anything, though? I.e. will it complain if the repositories aren't exact copies before the pull? Also, ideally the changes won't introduce conflicts, since the closed code will be in an entirely separate package. There will be changes in at least one file in the closed branch, though, the AndroidManifest.xml which changes the app name and such. Will Fossil be OK with merging changes that don't cause conflicts, even if the repositories aren't strictly in sync? I hope I can use Fossil in this scenario, as it would vastly ease the pain of trying to keep the proprietary version in sync with the open version. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] Non-synchronized Fossil repositories for same project, can it be done?
On 05/25/2011 01:05 PM, Gé Weijers wrote: Nolan, That should work just fine. I would put the closed-source variant in a separate branch, so they can pull your changes and either merge wholesale or cherrypick at will. The closed project will be a complete copy of the open project, plus added bits made specifically for their network. So if we can guarantee that automated pulls from the open project won't generate conflicts, then I'm all for doing that. Or, are you saying that the way to do this automation is to keep trunk a copy of the open project, then keep closed additions on a separate branch? If the only goal is to support cherrypicking then that isn't necessary, but if that's needed to avoid conflicts in automation then we'll do it that way. ___ 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] Non-synchronized Fossil repositories for same project, can it be done?
On Wed, May 25, 2011 7:13 pm, Nolan Darilek wrote: On 05/25/2011 01:05 PM, Gé Weijers wrote: Nolan, That should work just fine. I would put the closed-source variant in a separate branch, so they can pull your changes and either merge wholesale or cherrypick at will. The closed project will be a complete copy of the open project, plus added bits made specifically for their network. So if we can guarantee that automated pulls from the open project won't generate conflicts, then I'm all for doing that. Or, are you saying that the way to do this automation is to keep trunk a copy of the open project, then keep closed additions on a separate branch? If the only goal is to support cherrypicking then that isn't necessary, but if that's needed to avoid conflicts in automation then we'll do it that way. If you don't create a specific branch you will end up with accidental ones (forks) all over the place when you pull and you will have to merge them as they appear. I think that as soon as you have your clone you should open a working directory, change any settings as required, then fossil branch new master trunk -bgcolor yellow and tell everyone working proprietary to always use fossil open master, fossil update master etc. (unless they have their own branches, which should always be off master). Then you can have automated pulls from open at any interval you like, and merge trunk into master whenever it seems appropriate (or cherrypick - it might be wanted one day even though it is not the main reason for the extra branch). This is a variant on a Vendor Branch (http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#ThirdPartyLine) except that you pull frequently instead of just at release points). Eric ___ 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] fossil ui does not launch
On Tue, 24 May 2011 22:38:19 +0200, Gour-Gadadhara Dasa wrote: On Tue, 24 May 2011 22:31:27 +0200 Rene renew...@xs4all.nl wrote: I meant one version of fossil. Ahh..but how to do it when I did rebuild all the repos and newer fosiil involved changes in db schema? goto http://www.fossil-scm.org/ Tags -- release (I selected 047e06193b 2 releases back) SHA1 Hash: 047e06193b65c535d845d10f6e64d8c467ef7524 Date: 2011-04-13 12:05:18 User: drh Comment:Release Timelines: family | ancestors | descendants | both | trunk | release Other Links:files | Tarball | ZIP archive | manifest then fossil update 047e06193b65c535d845d10f6e64d8c467ef7524 make ./fossil rebuild ./fossil ui and voila a previous release But http://www.pcbsd.org/ claims 8.2 is the latest? Latest stable. Sincerely, Gour -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Add/commit from script?
Hello I'd like to write a script that the user can call that will... 1. Check if the document has already been added to the repository, and add it if not 2. Commit changes That way, the user won't have to call two commands. I was thinking of reading the output from fossil.exe ls, followed by fossil.exe commit (and check for either New_Version or nothing has changed): Is that the way to go? Thank you. ___ 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] Add/commit from script?
On 5/25/2011 6:07 PM, Gilles wrote: 1. Check if the document has already been added to the repository, and add it if not 2. Commit changes You can just add it every time. Adding a file that's already in the repo is a no-op. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] Add/commit from script?
On Wed, 25 May 2011 18:09:03 -0400, Joshua Paine jos...@letterblock.com wrote: You can just add it every time. Adding a file that's already in the repo is a no-op. Good to know. Thank you. ___ 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] Supporting markwon syntax for wiki
2011/5/24 Natacha Porté nata...@instinctive.eu: As a fossil user, I would love to have the option to use Markdown in the wiki (with the option of dumbing down to forbid inline HTML which might be unsafe -- exactly the same option as it exists today). To me, the benefit of a more conventional wiki syntax wiould be increased readability, especially for wiki pages. For tickets, Fossil's wiki syntax is very reasonable and rarely needs more than the most basic HTML. In-browser wiki rendering does work. And, using nowiki, the wiki source can be delivered to the browser. Aside from the fact this would require additional traffic between Fossil and the browser, this is roughly equivalent of a plug-in to Fossil. As for the safety of HTML, the subset that Fossil allows is no less safe than wiki syntax - errors in Fossil's HTML sanatizing not withstanding. ___ 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] Changing Fossil's Style (Skins) - A tutorial
On Sun, May 22, 2011 at 6:17 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: I personally would be interested in any advancements you make with javascript, or any other improvements from the basic fossil ui. Me as well. If you extend the GoCo theme to include diff highlighting (a list member posted an easy-to-use JS script for this), i will immediately import it into my sites :). -- - stephan beal The biggest problem of getting highlighting to work in fossil is the problem of choice: it's not easy to pick one JavaScript higlighter from the many ones that are available. For me, the winner is called highlight.js [1] Its killer feature is language auto-detection (you don't need to specify explicitly treat this code snippet as C/Python/diff/whatever and color it accordingly). A minor mismatch is that fossil puts code snippets inside pre blocks, while higlight.js looks for code inside precode blocks. This is easily mitigated by manually patching the code of highlight.js, as consequence no fiddling with fossil's source is required at all. Achieving diff highlight becomes trivial, one needs to pick only the diff.js file from the available languages when creating the bundle containing needed languages for a project and the general higlight machinery itself. The bundle is a big piece of javascript that is inserted directly into the repo header. A color template is chosen as well (highlight.js has a lot of them, as CSS) and is inserted into repo's CSS code. This is enough to get colored diffs everywhere and also colors for source code files as well, if support for languages included in a project is bundled. 1. http://softwaremaniacs.org/soft/highlight/en/ ___ 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] fossil ui does not launch
On Wed, 25 May 2011 23:42:58 +0200 Rene renew...@xs4all.nl wrote: make ./fossil rebuild ./fossil ui and voila a previous release Tried, but still does not work... :-/ I had to convert some repos to bzr (via git) ind order to continue commiting to them. :-/ Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
