Re: [fossil-users] Improvements to side-by-side diff
On Mon, Dec 17, 2012 at 10:27:09AM +0100, Paolo Bolzoni wrote: Maybe joining both ideas? Like coloring the whole word of a more neutral color and the difference with the usual bright color? I think it would be the best as I agree with both point of views. Fwiw, I'd prefer only the per-character differences to be highlighted. I quite like what 'meld' does, and that's what I'd like fossil to look like. :) Regards, Lluís. On Mon, Dec 17, 2012 at 10:03 AM, Martijn Coppoolse li...@martijn.coppoolse.com wrote: On 17-12-2012 8:33, Baruch Burstein wrote: Another suggestion: Since visual diffs are always for text files (I think), it doesn't make much sense to mark partial words as changed. If the whole word is not unchanged, then the whole word is changed. I am referring to things like line 73817 on the left in the fourth link below. Respectfully disagree. The line you refer to works perfectly fine; I see no reason to reduce granularity to word level, and every reason to keep it the way it works now: if a word is partially changed, I like to see _what_ part was changed. IMO, diff highlighting should highlight changes, not words. I can recognize words by myself just fine; seeing what exactly changed is what I need the highlighting for. Also, in my case (at least), visual diffs are usually for text files representing source code. In code, especially for a case-sensitive language, a change to a single character can be crucial. Reducing highlighting to only indicate changes per word makes it more difficult to see this. On Sat, Dec 15, 2012 at 4:16 AM, Richard Hipp d...@sqlite.org mailto:d...@sqlite.org wrote: Reposted from fossil-dev: OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 OLD: http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 NEW: http://www.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎɟı ˙pɐǝɥ ʎɯ uo buıʇʇıs uǝɥʍ ǝuıɟ ʇsnظ uʍop ǝpısdn pɐǝɹ uɐɔ ı ¡ʎןןıs ǝq ʇ’uop -- Martijn Coppoolse ___ 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 ___ 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] Possible bug in timeline?
- Mensaje original - De: David J. Weller-Fahy dave-lists-fossil-us...@weller-fahy.com Para: fossil-users@lists.fossil-scm.org CC: Enviado: Martes 18 de diciembre de 2012 3:39 Asunto: Re: [fossil-users] Possible bug in timeline? * Martin Gagnon eme...@gmail.com [2012-12-17 20:59 -0500]: Le 2012-12-17 à 20:34, David J. Weller-Fahy dave-lists-fossil-us...@weller-fahy.com a écrit : 1. Go to http://www.fossil-scm.org/fossil/timeline 2. Click Older 3. Click Newer 4. Click 200 Entries Note, the number of entries stays at 20. [snips] Can anyone else confirm? If so, I'll submit a bug. Same thing here... Thanks! Submitted: http://www.fossil-scm.org/index.html/tktview?name=9de46d5bf4 Regards, -- dave [ please don't CC me ] It's not a bug, there's only 21 timeline items since day 15. It's a coincidence. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] case-sensitive vs ignore-glob
Hi. It is a bug, or by design, that the ignore-glob does not honor the setting of case-sensitive? I haven't set case-sensitive, which means that on Windows defaults to false. Then: C:\work fossil set ignore-glob ignore-glob (local) *.zip,*.pdf,*.htm* C:\work fossil extras odi-llibres/GUGADESC.HTM Also, a nitpick. In the help for the extras command, the description of --ignore is truncated: Options: --abs-paths Display absolute pathnames. --dotfiles include files beginning with a dot (.) --ignore CSG ignore files matching patterns from the --rel-paths Display pathnames relative to the current working directory. Juanma ___ 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 vs. Git/Mercurial/etc.?
Hello, Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Please show your support for Fossil by adding to your stack on Ohloh.net
Hi! Fossil is pretty awesome. I believe more visibility will bring more users contributors and a good place for this is Ohloh.net What is Ohloh.net? Think of it as a Wikipedia-like semi-structured database about all FOSS projects. It helps to evaluate projects and having good information there increases the odds of attracting more developers users. Currently, Fossil is pretty low on this list: http://www.ohloh.net/tags/dvcs So please visit: http://www.ohloh.net/p/fossil-scm (or the page of any FOSS project you use) Then, click on the button I use this. You will need to create an account/login. I know it's a little demotivating because Fossil is not yet a supported SCM on Ohloh.net, but I believe if we show stronger stats, it increases our odds to change this. Here are some related discussions: https://www.ohloh.net/forums/3491/topics/6447 http://www.fossil-scm.org/index.html/tktview?name=0f36ec7790 More details about Ohloh.net and why I think it's useful/awesome: http://info.tiki.org/article168-Support-Tiki-and-your-favorite-Free-Open-Source-projects-on-Ohloh-net Thank you and best regards, -- Marc Laporte http://MarcLaporte.com http://Tiki.org/MarcLaporte http://AvanTech.net http://svg-edit.googlecode.com http://jquerysheet.googlecode.com http://sourceforge.net/p/jcapture-applet/ ___ 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 vs. Git/Mercurial/etc.?
On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] About Fossil support on SourceForge.net - log transcript from a discussion on #SourceForge IRC channel
Hi! Related to this ticket: Add support for the SourceForge.net Allura platform http://www.fossil-scm.org/index.html/tktview?name=311671db59 https://sourceforge.net/p/allura/tickets/5351/ Here is a chat log transcript from today: https://sourceforge.net/p/allura/chat/2012/12/18/#50d0d12a0594ca43fda36b20 What do you think? Best regards, -- Marc Laporte http://MarcLaporte.com http://Tiki.org/MarcLaporte http://AvanTech.net http://svg-edit.googlecode.com http://jquerysheet.googlecode.com http://sourceforge.net/p/jcapture-applet/ ___ 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 vs. Git/Mercurial/etc.?
On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer m...@mired.org wrote: well-balanced assessment. On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work from my recent experience , `autosync' seems to be _the_ feature making the move to DVCS tolerable for some die-hard `svn' users. spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. could you please elaborate on this? I came to fossil only very recently and, for now, have decided to keep the repo in the checkout directory (just like `hg', say). if I don't won't to have multiple checkouts from the same repo what's potentially bad about this setup? what kind of problems do you have in mind? j. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. the NetBSD example seems to indicate that fossil's has performance problems for such projects with a massive code base. is this still the state of affairs? not that this would matter for 99.9% of all projects. j. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 vs. Git/Mercurial/etc.?
On 12/18/12 22:29, Mike Meyer wrote: [---] I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. I don't think large team is a problem, apart from the manual work required in setting up users. I did some work a while back gluing together fossil with a security middleware which has an integrated identity manager. It reused the identity manager to configure fossil server instances. I did some quick'n'dirty hacks; like opening up the repository via libsqlite and manipulated the databases directly, which didn't feel all too excellent. (Though the whole thing was a proof-of-concept and something to demo, more than anything else). My primary experience from that project was that there are some areas where fossil could be enhanced to allow easier integration with identity managers, which could ease user-management for very large teams. The biggest problem I have encountered with fossil is with regards to scalability. Anyone who has tried to use the NetBSD fossil repository knows it's a pretty painful experience. With that said, I came to fossil from bazaar which I abandoned because it had scalability issues (which were even worse), so it's not an exclusive fossil-problem. (git isn't affected by this though, but it's noteworthy that the NetBSD project on github is (was?) imported from the fossil NetBSD repository). -- Kind regards, Jan Danielsson ___ 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] Improvements to side-by-side diff
Hi! How about some links for previous and next commit? Thanks! M ;-) On Fri, Dec 14, 2012 at 9:16 PM, Richard Hipp d...@sqlite.org wrote: Reposted from fossil-dev: OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 OLD: http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 NEW: http://www.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 Comments, suggestions, and (constructive) criticism are all welcomed. Also welcomed are examples of diffs that do not perform well using the new diff logic. Note that I will eventually update the Fossil executables on the OLD machines above, so if you are viewing this more than a week or so after it was posted (2012-12-14) then the OLD and NEW will likely look the same. -- 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 -- Marc Laporte http://MarcLaporte.com http://Tiki.org/MarcLaporte http://AvanTech.net http://svg-edit.googlecode.com http://jquerysheet.googlecode.com http://sourceforge.net/p/jcapture-applet/ ___ 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 vs. Git/Mercurial/etc.?
On Tue, 18 Dec 2012 23:50:17 +0100, Jan Danielsson
jan.m.daniels...@gmail.com wrote:
On 12/18/12 22:29, Mike Meyer wrote:
[---]
I don't know of anyone using it for a large team. I don't know of any
reason not to, except for the risk of being the first to try that.
I don't think large team is a problem, apart from the manual work
required in setting up users. I did some work a while back gluing
together fossil with a security middleware which has an integrated
identity manager. It reused the identity manager to configure fossil
server instances. I did some quick'n'dirty hacks; like opening up the
repository via libsqlite and manipulated the databases directly, which
didn't feel all too excellent. (Though the whole thing was a
proof-of-concept and something to demo, more than anything else).
My primary experience from that project was that there are some areas
where fossil could be enhanced to allow easier integration with identity
managers, which could ease user-management for very large teams.
even for small teams I'd prefer to be able to do user management (easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui? some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
would be nice to have. fine-tuning might be delegated to the webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
The biggest problem I have encountered with fossil is with regards to
scalability. Anyone who has tried to use the NetBSD fossil repository
knows it's a pretty painful experience.
With that said, I came to fossil from bazaar which I abandoned
because it had scalability issues (which were even worse), so it's not
an exclusive fossil-problem. (git isn't affected by this though, but
it's noteworthy that the NetBSD project on github is (was?) imported
from the fossil NetBSD repository).
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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 vs. Git/Mercurial/etc.?
On 12/18/12 22:50, j. v. d. hoff wrote: the NetBSD example seems to indicate that fossil's has performance problems for such projects with a massive code base. is this still the state of affairs? Last time I used my NetBSD fossil repository, it was still pretty much unusable. I don't think anything has changed on that front since then. I have a pretty high-powered PC, and it still takes a few hours for rebuilds. For a friend of mine, who has a Pentium3-class system, pulling latest changes and rebuilding the NetBSD fossil repository takes around ~24h each time. not that this would matter for 99.9% of all projects. Definitely true. -- Kind regards, Jan Danielsson ___ 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 vs. Git/Mercurial/etc.?
On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. -- 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 vs. Git/Mercurial/etc.?
On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. relieved to here that, thanks. are there any other valid arguments (beyond matter of taste things like I want to separate the repo from the checkout and facilitating backups by putting all repos in a single place) which make it unwise to keep the repo within the checkout? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 vs. Git/Mercurial/etc.?
On Wed, 19 Dec 2012 00:02:11 +0100
j. v. d. hoff veedeeh...@googlemail.com wrote:
even for small teams I'd prefer to be able to do user management (easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui?
Nope, it doesn't.
some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
It's not quite that easy - you have to mangle one user at a time, and
user creation is it's own command.
would be nice to have. fine-tuning might be delegated to the webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
I'd say it is. It could be better, but it's there. I generally wind up
running a shell loop:
for u in $DEVS ADMINS $READERS
do
# create user name from company mail address, password is PWname.
fs new $u $u...@company.com PW$u -R $REPO
done
for dev in $DEVS
do
# Set up developers
fs cap $dev v -R $REPO
done
Setting up new users in mass doesn't make a lot of sense - you
probably want to set contact information and passwords separately
anyway. Setting permissions (capabilities) for a group would be a nice
enhancement.
mike
--
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.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 vs. Git/Mercurial/etc.?
thanks for clarifying this. gonna check the help pages before spamming the
list again
On Wed, 19 Dec 2012 00:33:29 +0100, Mike Meyer m...@mired.org wrote:
On Wed, 19 Dec 2012 00:02:11 +0100
j. v. d. hoff veedeeh...@googlemail.com wrote:
even for small teams I'd prefer to be able to do user management
(easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui?
Nope, it doesn't.
some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
It's not quite that easy - you have to mangle one user at a time, and
user creation is it's own command.
would be nice to have. fine-tuning might be delegated to the
webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
I'd say it is. It could be better, but it's there. I generally wind up
running a shell loop:
for u in $DEVS ADMINS $READERS
do
# create user name from company mail address, password is PWname.
fs new $u $u...@company.com PW$u -R $REPO
done
for dev in $DEVS
do
# Set up developers
fs cap $dev v -R $REPO
done
Setting up new users in mass doesn't make a lot of sense - you
probably want to set contact information and passwords separately
anyway. Setting permissions (capabilities) for a group would be a nice
enhancement.
mike
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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 vs. Git/Mercurial/etc.?
On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. relieved to here that, thanks. are there any other valid arguments (beyond matter of taste things like I want to separate the repo from the checkout and facilitating backups by putting all repos in a single place) which make it unwise to keep the repo within the checkout? Capabilities to work on multiple different checkout associated with different branch/revision/tag using the same repo file. Example: - $ mkdir checkout $ cd checkout ## a checkout for the trunk $ fossil open ~/repos/a_repo.fossil ... $ cd .. $ mkdir checkout_some_branch $ cd checkout_some_branch ## a checkout for the branch some_branch using the same repo file. $ fossil open ~/repos/a_repo.fossil some_branch - That is a killer feature for me. This is impossible to do with git or hg. Eg. with git, each checkout have to be a different clone with their own .git directory which contain the whole history. Regards -- Martin G. ___ 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 vs. Git/Mercurial/etc.?
On Wed, 19 Dec 2012 01:04:19 +0100, Martin Gagnon eme...@gmail.com wrote: On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer m...@mired.org wrote: I don't do that (I keep all my fossil repositories in ~/repos), so haven't paid close attention to the issues. The big one seems to be accidentally trying to add the repository to itself. The resulting checkin never terminates. I also recall problems with Windows (something else I don't use) where the solution was to move the repository out of the work space. Maybe the people who helped solve the problems can comment on this? Or maybe my skimming of such problems has led me to a false conclusion. I think all these problems are fixed and that it is safe to keep the repo in the check-out directory. relieved to here that, thanks. are there any other valid arguments (beyond matter of taste things like I want to separate the repo from the checkout and facilitating backups by putting all repos in a single place) which make it unwise to keep the repo within the checkout? Capabilities to work on multiple different checkout associated with different branch/revision/tag using the same repo file. Example: - $ mkdir checkout $ cd checkout ## a checkout for the trunk $ fossil open ~/repos/a_repo.fossil ... $ cd .. $ mkdir checkout_some_branch $ cd checkout_some_branch ## a checkout for the branch some_branch using the same repo file. $ fossil open ~/repos/a_repo.fossil some_branch - That is a killer feature for me. This is impossible to do with git or hg. Eg. with git, each checkout have to be a different clone with their own .git directory which contain the whole history. OK, I see what you mean, but this wouldn't be important for me AFAICS. actually I don't see any real advantage of this approach compared to simply updating to the respective branches in turn in order to work on them. so (for me) this would fall under the matter of taste category (which still means it's nice that it can be done). j. Regards -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 vs. Git/Mercurial/etc.?
On Tue, Dec 18, 2012 at 03:29:19PM -0600, Mike Meyer wrote: On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. Monotone also works as a self-contained binary (written in C++, with more library dependencies, but all can be statically linked if desired). And it has a centralised database, from where you can have multiple checkouts and multiple repositories. And it has a very powerful tagging mechanism. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
