On Mon, Dec 31, 2012 at 8:21 AM, Jan Danielsson
wrote:
> On 12/31/12 11:17, Nico Williams wrote:
>> But I feel I must at least address this
>> insinuation that I was trolling.
>It's obvious that you aren't trolling. You don't have to defend
> yourself against such nonsense.
At this point, I'd
Nico Williams wrote:
>Go back through those 30 posts you mentioned. Go back to the very
>first one from me. I tried to be concise and wrote just three
>paragraphs that, IMO, captured what was needed. I certainly did not
>say "I want git rebase in fossil" and then watched the fireworks --
>no,
Nico Williams wrote:
>On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter
> wrote:
>> On 30 December 2012 12:56, Nico Williams
>wrote:
>>> What is it about rebase that causes so many to miss the idea of a
>>> rebase that is NOT destructive because it creates a new branch
>instead
>>> of doing a d
Nico Williams wrote:
>On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote:
>>>> So, for the third time, can you describe your proposed new feature
>>>*without* saying the words "git" or "rebase".
>>>No: it's too much work, and many peop
Nico Williams wrote:
>What I'm proposing is that in fossil the rebase operation create a new
>branch named after the currently checked out branch (or named by the
>> So, for the third time, can you describe your proposed new feature
>*without* saying the words "git" or "rebase".
>No: it's too mu
Nico Williams wrote:
>On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote:
>> You missed the point. Nothing should *ever* be rebased. It's a
>rewrite of history, which is a fundamentally bad thing. While a SCM
>should make generating patch files easy, it shouldn't req
Nico Williams wrote:
>tl;dr: we agree that public history should not get rewritten. You
>missed the point of when, where, and why I need rebase.
Which is why I asked for clarification about that point. See below.
>On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote:
>> Nico
On Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov
wrote:
> I suggest you to calm down. I see my plead to not being zealous was in
> vain, so just please calm down at least.
I am calm. Yes, I'm a little bit bothered about being insulted in
various ways, but I'm trying to return the discussio
On Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov
wrote:
> In the first message of these, Mike Meyer, first ruled out the whole
> tool (Git) due to hating its optional feature
If you're going quote someone out of context, at least get their reasons right.
You called rebase a &quo
Nico Williams wrote:
>Rebase is one of teh killer features of git.
It certainly kills any interest I have in using git on a regular basis.
>How many times have you submitted a patch to an upstream and then been
>told to make a bunch of changes, re-organize your commits, make
>specific changes
Stefan Bellon wrote:
>On Fri, 28 Dec, Richard Hipp wrote:
>> When somebody clones the repository,and has a local copy of the
>> repository, then they can do anything they want with that local copy
>> since it is a file they own. Permissions only come into plan when
>> dealing with a remote serv
Michael Richter wrote:
>On 19 December 2012 07:33, Mike Meyer wrote:
>> for u in $DEVS ADMINS $READERS
>> do
>> # create user name from company mail address, password is PW.
>> fs new $u $u...@company.com PW$u -R $REPO
>> done
>>
>> for dev in
On Thu, Dec 20, 2012 at 2:11 PM, j. v. d. hoff
wrote:
> On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer wrote:
> I'm just proposing to automate what you do manually in the considered
> situation (including chosing a different local password, why not?): create
> the user, mak
On Thu, Dec 20, 2012 at 11:56 AM, j. van den hoff
wrote:
> I would find it far more intuitive if _after_ a `clone' of the above sort
> (password query for `myname' and all) the corresponding local user would
> be created automagically and also be set to the default user so that I'm
Nothing to do
On Wed, 19 Dec 2012 12:06:05 +0100
Remigiusz Modrzejewski wrote:
> On Dec 18, 2012, at 14:42 , Gilles wrote:
> > 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 t
On 12/18/12, j. v. d. hoff wrote:
> On Wed, 19 Dec 2012 01:04:19 +0100, Martin Gagnon wrote:
>> Capabilities to work on multiple different checkout associated with
>> different branch/revision/tag using the same repo file.
>>
>> Example:
>> -
>> $ mkdir
On Wed, 19 Dec 2012 00:02:11 +0100
"j. v. d. hoff" 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.
On Tue, 18 Dec 2012 22:50:56 +0100
"j. v. d. hoff" wrote:
> On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer wrote:
> well-balanced assessment.
Thank you.
> > apart as a DSCM is autosync mode and that you can have multiple work
> > spaces checked out of the same repo
On Tue, 18 Dec 2012 14:42:34 +0100
Gilles 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
f
I don't really care which behavior is the default. I've dealt with
both long enough that neither is surprising, and my workflow doesn't
change enough to notice for this. I'm just tired of seeing the bogus
claim that one is somehow "surprising" and "natural" and one isn't.
The only thing I want to
On 12/12/12, Themba Fletcher wrote:
> to alias 'fossil rm' to 'fossil rm -f'.
That is a disaster waiting to happen. If the user in question forgets
that they've done that, and then runs a series of commands from
someone who *didn't* do that (either cut-n-paste from an answer on the
list or the we
Stefan Bellon wrote:
>I'd rather vote for a "list all matching revisions"
>in the --all case and the default behaviour to stop at the "most recent
>match".
I think there are three cases, the third being the earliest matching revision.
Especially if the current revision is a match. Having the d
On Mon, Nov 19, 2012 at 6:13 PM, Richard Hipp wrote:
> On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff
>> mostly I would like to get information here whether there are changes
>> (edits, adds, removals...) or not and what files are not tracked.
>> `hg stat' does provide that. in fossil I have to d
On Mon, 15 Oct 2012 10:14:42 +0200
Gour wrote:
> On Sat, 19 Feb 2011 06:25:32 -0500
> Mike Meyer wrote:
>
> > Any other zsh users out there? If so
> >
> > I couldn't find a fossil backend for the vcs_info facilities in zsh
> > (an API to extract info
On Sat, 13 Oct 2012 09:27:38 -0400
Richard Hipp wrote:
> On Sat, Oct 13, 2012 at 4:06 AM, Gour wrote:
> > Now, I'm curious about some of the items from the TODO list
> > (http://www.fossil-scm.org/index.html/wiki?name=To+Do+List)
> > and their status:
> >
> > * Uncommit
> > All what I need is si
Remigiusz Modrzejewski wrote:
>On Oct 10, 2012, at 14:28 , Mike Meyer wrote:
>> Well, the lack of an in-binary API certainly isn't the reason there's
>not an Eclipse plugin. The Eclipse license is incompatible with the
>GPL, so any scm that's GPL'ed (*co
Remigiusz Modrzejewski wrote:
>>> Actually... No. Fossil, with it's monolithic single-app design, is
>>> relatively hard to both extend and embed.
>>
>> Actually there are two kinds of people in the world, those who expect
>> something to do whatever they think it should, and those who look at
On Thu, 27 Sep 2012 15:30:38 +1000
Christopher Vance wrote:
> The binary runs fine if the shared libraries used on your distribution
> have the same version numbers as those the binary is compiled against,
> and assuming the same library source version gets to be the same
> library runtime version
Michal Suchanek wrote:
>On 14 September 2012 18:49, Mike Meyer wrote:
>> Wes Freeman wrote:
>>>The fact of the matter, though, is you can choose whether you want to
>use
>>>that feature of git or not; you're certainly not forced to use it.
>> Well
Wes Freeman wrote:
>The fact of the matter, though, is you can choose whether you want to use
>that feature of git or not; you're certainly not forced to use it.
Well, you can choose whether or not to use it locally. But once you share the
repo, anyone you pull from can use it and force you to
On Fri, Sep 14, 2012 at 8:35 AM, Michal Suchanek wrote:
> The thing to which promoters of immutable history are blind is that
> while exact history record of development of particular feature might
> be interesting and educational it is not the primary purpose if VCS.
That depends on what you're
On Mon, 02 Jul 2012 23:21:39 +0200
ahrens wrote:
> I should add that openssl is installed:
> $ which openssl
> /usr/bin/openssl
That's the binary, not the bits you need to compile code that uses
it. Just one of the many reasons I develop on FreeBSD: they don't do
that. If you had openssl installe
On Mon, 2 Jul 2012 08:08:18 -0400
Richard Hipp wrote:
> I am willing to *consider* some option that says "do not commit these
> files, even if they change, unless that are specifically named on the
> command-line". I think this would be easy to implement by messing
> with the is_selected()/if_se
On Tue, 19 Jun 2012 18:07:58 +0200
Stephan Beal wrote:
> Yesterday i got a tcc-based compiler for my tablet and i am curious if any
> of you have gotten fossil to compile (perhaps cross-compiling?) on (or for)
> Android?
There's been some work done on cross-compiling. If you google for
"compile
On Tue, Jun 12, 2012 at 8:48 PM, Stephan Beal wrote:
> On Tue, Jun 12, 2012 at 11:18 PM, Mike Meyer wrote:
>>
>> ACLs. Apparently, using it means that you have to open the sources up
>> to readable by everything/everyone or some such. That's caused him to
>
On Tue, 12 Jun 2012 14:45:37 -0400
Ron Wilson wrote:
> In particular, file/directory names with spaces in them need to be
> quoted.
The other issue is that fossil doesn't pay attention to Windows
ACLs. Apparently, using it means that you have to open the sources up
to readable by everything/every
On Tue, 12 Jun 2012 00:15:08 +0100
Jacek Cała wrote:
> Hi,
>
> Could you please be a bit more specific about what errors exactly you
> have experienced.
I wish I could. It's my boss that's having problems, and I've already
sent the full report to him. I'm now pursuing this on my own time.
> I'
On Tue, 12 Jun 2012 10:32:14 +0300
Baruch Burstein wrote:
> On Tue, Jun 12, 2012 at 1:36 AM, Mike Meyer wrote:
> > On Tue, 12 Jun 2012 00:06:38 +0200
> > Stephan Beal wrote:
> > > On Mon, Jun 11, 2012 at 10:01 PM, Baruch Burstein > >wrote:
> > > >
My boss just sent me mail that said, and I quote:
Fossil sucks and is actually not compatible with Windows
I'm pretty sure I've seen people here who use it no Windows, and
there's a Windows distribution, which makes me think he's wrong.
His problem is that he has lots of spaces in his directo
On Tue, 12 Jun 2012 00:06:38 +0200
Stephan Beal wrote:
> On Mon, Jun 11, 2012 at 10:01 PM, Baruch Burstein wrote:
>
> > +** (versionable) text files which should have CR+NL line endings
> > +** automatically fixed to CR
> LOL! As much as i agree with the sentiment, isn
Thomas Stover wrote:
>On Thu, 31 May 2012 13:44:52 +1000
>"Chen, Zon" wrote:
>> So ideally we want to be able to limit Fossil's Administrator account
>> to only work from the local PC (or better yet, from LAN only.)
>ok that makes sense. I do know that you can "unlock" the admin account
>by just d
I found a number of people asking about this, but none of them seemed
to have gotten an answer...
Is there some way to set the "use REMOTE_USER for authentication"
setting from the command line (or more accurately, a script)? I could
just create a configured empty repository and copy that, but tha
On Mon, 7 May 2012 14:16:59 +0200
Jiri Navratil wrote:
> I made a typo in Wiki page. Can I rename Wiki page or delete a Wiki page?
In one sense, no. Artifacts are forever (though you can shun
them). However, if you delete all the text from a page, it'll vanish
from the list of wiki pages.
[Drifting off topic here...]
On Fri, 20 Apr 2012 14:25:59 -0400
Miles Fidelman wrote:
> Mike Meyer wrote:
> > On Fri, 20 Apr 2012 10:26:26 -0700
> > Andreas Kupries wrote:
> >
> >> On 4/20/2012 7:34 AM, Mike Meyer wrote:
> >>> ... Things like architectu
On Fri, 20 Apr 2012 10:26:26 -0700
Andreas Kupries wrote:
> On 4/20/2012 7:34 AM, Mike Meyer wrote:
> > ... Things like architectural diagrams wind up there, and ...
>
> I like to program my diagrams, instead of drawing them. Easier to change, and
> the code (aka text) is nic
On Fri, 20 Apr 2012 09:50:02 -0400
Miles Fidelman wrote:
> Just started using Fossil for a new project - it just seems so much
> easier than git, and the integrated wiki and ticketing system just
> simplifies things a lot.
Yup.
> A question to the group: To what extent are any of you using F
On Mon, 5 Mar 2012 18:12:15 -0500
Richard Hipp wrote:
> On Mon, Mar 5, 2012 at 6:03 PM, Christopher Berardi
> wrote:
> > (n+2) Have a compile-time configuration option to choose what to
> > build into fossil. For example, maybe I just want the 'core'
> > vcs without the wiki, ui
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland wrote:
> On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh
> wrote:
>> On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
>> > If I do:
>> > fossil rm some/file.txt
>> > rm some/file.txt
>> fossil commit
> People often prefer to commit when their wo
On Wed, Feb 1, 2012 at 8:03 AM, Leo Razoumov wrote:
> On Wed, Feb 1, 2012 at 07:08, Richard Hipp wrote:
>> The clock according to the "D" card of the artifact.
>>
>> In other words, you can keep changing the value of a tag and the latest
>> version always wins.
>>
>> If two people change the valu
On Fri, 27 Jan 2012 07:48:09 +
Baptiste Daroussin wrote:
> Nice one usually the zsh project prefers to have it incorporate
> upstream so do not hesitate to send your contribution to the
> zsh-workers mailing list also and because you are working on
> zsh+fossil did you already have a look at v
On Thu, 26 Jan 2012 20:54:19 +0100
Lluís Batlle i Rossell wrote:
> On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote:
> > On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski
> > > http://nuclearsquid.com/writings/git-add/
> > >
> > > Any opinions?
> > >
> >
> > I'm of the old-fash
On Thu, 22 Dec 2011 20:15:35 -0500
Richard Hipp wrote:
> The rmdir(2) system call on Posix is a no-op if the directory is not
> empty. So I was thinking that we could just invoke rmdir() (or
> _rmdir() on windows) on the directory of a file every time a file is
> deleted, and let the OS worry ab
On Thu, 22 Dec 2011 10:06:47 -0500
Tomek Kott wrote:
> -1 renaming rm to untrack or something similar that conveys
> correct message -- personally I think of "fossil rm" as acting on the
> repository. So I am, in fact, removing the file from the repository.
Except you're not removing the file fro
On Wed, 21 Dec 2011 19:44:50 -
"Eric" wrote:
> On Wed, December 21, 2011 7:31 pm, Mike Meyer wrote:
> > On Wed, 21 Dec 2011 20:21:18 +0100
> > Ramon Ribó wrote:
> >> > Another issue is that an SCM system is _not_ a backup tool, but
> >> > m
On Wed, 21 Dec 2011 20:21:18 +0100
Ramon Ribó wrote:
> > It is not the job of the SCM system to keep in step with my working
> > directory
> Why not? In that case, "fossil update" shouldn't delete files that
> have been removed from repository, but it does.
Any chance of getting rm/delete's name
On Wed, Oct 26, 2011 at 12:28 PM, Kevin Ar18 wrote:
> Perhaps I should explain more about it? At this stage, I am mostly using
> the VCS to backup and keep track of a single directory structure. (Of
> course I may use it for other purposes.) Point is, it would be really
> difficult to have to t
2011/10/20 Lluís Batlle i Rossell
> On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote:
> > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment
> wrote:
> > How about an having a way to flag files - when created - as "read-only"
> or
> > some such. (I
On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment wrote:
> I'm a novice Fossil user working in a small group with need
> to track both text and binary files.
>
> It seems to me that locks are nice to have for text files
> since 3 way diffs can be merged at relatively little cost.
> But inability
On Thu, Oct 20, 2011 at 3:46 AM, Martin Gagnon wrote:
> On 2011-10-20, at 01:13, Jeff Slutter wrote:
>
> > A couple weeks ago I posted about the possibility of a new configuration
> setting called something like "allow-binmerge" (default off). If it is
> enabled, and there is a gmerge-command se
On Wed, 19 Oct 2011 16:24:17 -0700
Matt Welland wrote:
> I sent out a description of how I think light weight "locks" could be
> implemented on top of fossil in a past email. In fact I'm making some good
> progress on implementing what I want in a wrapper around fossil (implement
> locks in addit
2011/10/19 Lluís Batlle i Rossell
> On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote:
> > This requires a lot of work on fossils part in order to be reliable.
> If I had to implement that on fossil, I'd use some kind of table like the
> shun
> table, propagated
This requires a lot of work on fossils part in order to be reliable. Unlike
source changes, you can't do a commit and then require a merge before
pushing if there's a collision. There are also nasty restrictions on how you
do things. In particular, you have to have autosync on (or ignore it if off)
On Mon, Oct 10, 2011 at 9:16 AM, Stephan Beal wrote:
> Personally, I find the "colorize the code on the client" hacks incredibly
>> wasteful. You could colorize it once when you generate it, but instead you
>> colorize it every time someone wants to read it? Talk about a silly waste of
>> CPU. Or
On Mon, Oct 10, 2011 at 8:20 AM, Stephan Beal wrote:
> On Mon, Oct 10, 2011 at 4:04 PM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
>
>> All those flashy JS bells and whistles consistently make me think
>> they're really there for the sake of being there.
>>
>
> But what bette
On Wed, Oct 5, 2011 at 11:38 AM, Michal Suchanek wrote:
> On 5 October 2011 20:12, Mike Meyer wrote:
> > On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
> > wrote:
> >>
> >> That sort of "we don't need it, we don't need it" mant
On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> That sort of "we don't need it, we don't need it" mantra is a typical
> case of the famous "Blub paradox".
> I mean, if we have two DVCS tools one of which makes you able to
> rewrite history and anoth
On Tue, Oct 4, 2011 at 1:50 PM, Erlis Vidal wrote:
> You shun a commit or a file in a commit? Is in fossil the shun generating a
> different commit?
>
> you can delete with git files that has history with
>
> git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch
> file_name' HEAD
On Tue, Sep 20, 2011 at 12:00 PM, Martin S. Weber wrote:
> If you have fossil as a library, having something to remote-control the
> fossil library is the next logical step. Of course if you're an IDE person,
> you'll appreciate easier integration with, say, the behemothian eclipse, the
> leviatha
On Thu, Sep 1, 2011 at 11:20 AM, Dmitry Chestnykh
wrote:
> > but it's not clear the openssl code is always a win... I'm not sure
> whether or not it's a good idea to try to determine at run time which to use
> (since the check overhead has to be measurable after all).
>
> Yes, let's leave it as it
On Thu, Aug 18, 2011 at 1:44 PM, Jos Groot Lipman wrote:
> >>
> >>"The tag works like with the addition that it also
> >>disables all wiki and HTML markup through the matching ."
> >>
> >>But why this special tag? Is this not something the should do
> >>under all circumstances? When would you
Jos Groot Lipman wrote:
>I also found out about this
>http://www.fossil-scm.org/index.html/wiki_rules
>
>"The tag works like with the addition that it also
>disables
>all wiki and HTML markup through the matching ."
>
>But why this special tag? Is this not something the should do
>under
>all
On Mon, Aug 15, 2011 at 10:49 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> On Sun, 14 Aug 2011 19:16:50 -0700
> Mike Meyer wrote:
>
> [...]
> > If you insist on them being files, then there's not much point in
> > further discussion. And
On Sat, 13 Aug 2011 09:48:09 +0100
Ben Summers wrote:
> On 12 Aug 2011, at 22:39, Mike Meyer wrote:
> > On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers wrote:
> >> On 12 Aug 2011, at 20:44, Mike Meyer wrote:
> >> > On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym
&
On Fri, Aug 12, 2011 at 3:42 PM, Richard Hipp wrote:
>
>
> On Fri, Aug 12, 2011 at 5:24 PM, Remigiusz Modrzejewski <
> l...@maxnet.org.pl> wrote:
>
>>
>> On Aug 12, 2011, at 22:28 , Ben Summers wrote:
>>
>> >> If it has to be in the file system, I'd prefer one file to many. At the
>> very least,
On Fri, Aug 12, 2011 at 2:44 PM, Stephan Beal wrote:
> On Fri, Aug 12, 2011 at 11:39 PM, Mike Meyer wrote:
>
>> space. But we already have __FOSSIL__, so (in the words of Arlo Guthrie)
>> one big pile is better than two little piles.
>>
>
> For the benefit
On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers wrote:
> On 12 Aug 2011, at 20:44, Mike Meyer wrote:
> > On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym <
> ala...@snell-pym.org.uk> wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >&
On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/12/2011 07:10 PM, Joshua Paine wrote:
> > On 8/12/2011 1:50 PM, altufaltu wrote:
> >> 1. Versioned settings: I'd prefer having all settings in a single
> >> text file with name="va
On Thu, Aug 11, 2011 at 2:03 PM, Stephan Beal wrote:
> There is no built-in way to create a remote repository (a fossil server
> represents the _one_ repository which must already exist before the server
> can start). You have to create the .fsl file, run fossil ui once to set the
> admin passwor
On Tue, Aug 9, 2011 at 8:35 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> On Tue, 9 Aug 2011 08:19:46 -0700
> Matt Welland wrote:
>
> > I often am planning a change or thinking ahead and will create the
> > branch to record my intentions before I've started coding. I do like
On Mon, 25 Jul 2011 23:20:31 -0700
Russ Paielli wrote:
> I posted a recommendation for Fossil earlier today on a Scala forum (see my
> earlier post today on this forum). I got this reply:
>
> And [Fossil] is reported to destroy repositories if someone branches:
> http://sheddingbikes.com/posts/1
On Mon, 18 Jul 2011 21:18:29 -0700
Jeremy Anderson wrote:
> Out of curiosity, why are you converting from mercurial?
While you weren't asking me, I converted from mercurial (and did the
hg -> git -> fossil path) to fossil, so feel an answer from me isn't
unreasonable.
> I ask because my friends
On Wed, 13 Jul 2011 19:30:08 -0400
Joshua Paine wrote:
> On 7/13/2011 7:13 PM, Brian Cottingham wrote:
> > was wondering if some of the Fossil internals
> > could be refactored to not need an explicit 'open' command. I.E., Git
> > and SVN don't need an open command- you just cd into a repo's direc
On Tue, 14 Jun 2011 22:55:18 -0700
Matt Welland wrote:
> I thought that from an end user perspective all that is needed with autoconf
> is sh.
Not quite true. The problem is that, while every system has a /bin/sh,
different systems use different shells for that: most (but not all)
GNU/Linux syste
On Tue, 14 Jun 2011 17:37:06 -0400
David Slocombe wrote:
> But autotools should come first as it both supports the above and
> goes at least a long way to helping all the other folks who aren't
> plugged into some Linux distribution's binary package system.
Is autotools the only such tool the fe
On Mon, 13 Jun 2011 19:27:49 -0400
Richard Hipp wrote:
> On Mon, Jun 13, 2011 at 7:07 PM, Steve Havelka wrote:
>
> > Is it necessary that it's autoconf? Or would you take a CMake-based build
> > script?
> ccmake is not installed by default on either my iMac nor my SuSE Linux
> desktop. So it
I recently ran into a merge scenario that most DSCMs seem to fail, but
fossil gets right. See the attached fstest.sh for an example.
The question is - is fossil just lucky, or is it looking at the
intermediate revisions in the merge instead of doing a pure 3-way
merge?
Thanks,
Getting pedantic here...
On Thu, 7 Apr 2011 12:55:14 -0400
Richard Hipp wrote:
> On Thu, Apr 7, 2011 at 12:42 PM, Ramon Ribó wrote:
> > MacOSX is using UNIX line ending since more than 10 years-ago.
> > In modern computers, there are two options:
> > Unix/MacOSX: LF
> Also, Solaris, AIX, HPUX, N
I know I can embed an image file that's stored in the SCM. I'd like to
embed - instead of just link to - an image file that's attached to a
wiki page. Is that possible? If so, what's the syntax. The obvious
things didn't work for me, and google just lists this as a "TODO".
thanks,
On Mon, 28 Mar 2011 14:17:10 -0400
Volodya Savastiouk wrote:
> I've raised this issue before with little success, although a few people
> responde> The issue is the file dates being always today's date whenever one
> downloads a copy from
> the repository or simply opens a local copy. I'd real
On Mon, 21 Mar 2011 09:17:14 -0400
Richard Hipp wrote:
> On Mon, Mar 21, 2011 at 9:05 AM, Wilson, Ronald wrote:
>
> > I have been using the ignore-glob feature for a while now, but it doesn’t
> > seem to be working for some of the files that I think should be covered by
> > the glob. As you c
On Fri, 11 Mar 2011 19:40:03 +1000
Steve Dalton wrote:
> Should things like "lock" and "rebase" be "no" as apposed to
> "Unknown"? I understand rebase is something that can't be done in
> Fossil due to "fossilizing" the history right? I'm also certain fossil
> doesn't support locking, right? :)
On Fri, 11 Mar 2011 18:53:55 +1000
Steve Dalton wrote:
> Maybe we should start a comparison table on the wiki
> svn/git/mercurial/fossil equivalent commands
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_Commands
Though it doesn't cover the command in questio
On Fri, 4 Mar 2011 12:59:12 +
Stephen De Gabrielle wrote:
> Some logo ideas:
>
> t-rex 'Exciting!'
> http://t1.gstatic.com/images?q=tbn:ANd9GcQeEF1HR0h6BpVnOpRq3wMhFl9DOkh2j7nA7VzALlWdDqstpI68EA
Um, no. "Exciting" is the *last* thing I want from a VCS!
In looking at the other DVCS sites (a
On Wed, 2 Mar 2011 17:54:15 +0200
"John Found" wrote:
> Also look at other similar systems - "Bazaar" - makes allusion with crowds of
> developers. "Mercurial" - something very agive, quick, versatile.
Mercurial also means erratic, fickle, liable to sudden unpredictable
changes. You really want
On Mon, 28 Feb 2011 07:21:58 +1000
Steve Dalton wrote:
> Hi Mike
> Would like care to share what you did to get it working (ie. LDFLAGS
> etc) - I wouldn't mind having a try myself just to see what the
> process is.
> Thanks
> Steve
Sure.
Note that setting TCC in makemake.tcl doesn't work for b
On Sat, 26 Feb 2011 20:53:11 -0800 (PST)
Timothy Brown wrote:
> For your consideration,
>
> How hard would it be to build Fossil for Android? For that matter how hard
> would it be to get Fossil built for iOS?
Since both are Unix variants, it shouldn't be to bad. The makemake
script already h
On Tue, 22 Feb 2011 07:09:14 +0200
Ron Aaron wrote:
> One feature "missing" from Fossil is a way to restrict checkins on the
> 'trunk'
> (or other branch) to certain people.
>
> This is necessary in a group where the methodology is for a "gatekeeper" to
> approve integration into the main lin
Any other zsh users out there? If so
I couldn't find a fossil backend for the vcs_info facilities in zsh
(an API to extract info from various vcs's to display in your prompt),
so I wrote one.
No archives yet, but it's available from a chiselap repo at:
https://chiselapp.com/user/mwm/reposito
On Wed, 16 Feb 2011 13:38:08 -0500
Ron Wilson wrote:
> On Wed, Feb 16, 2011 at 12:03 PM, Chad Perrin wrote:
> > I've been rummaging through the list archives, and sifting through the
> > Web documentation, but I am still not clear on the status of using SSH to
> > encrypt connections for push/pu
On Mon, 7 Feb 2011 11:51:29 -0500
Richard Hipp wrote:
> On Mon, Feb 7, 2011 at 11:45 AM, Justin Mazzi wrote:
> > Two questions regarding signing.
> > 1) Can you enforce the signing of commits on the server's side?
> > 2) Can a list of accepted keys be used? I wanna make sure the developers
> > ar
1 - 100 of 102 matches
Mail list logo
