On Mon, Mar 2, 2015 at 6:30 AM, Richard Hipp d...@sqlite.org wrote:
Ben Pollack's essay at
http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/
succinctly points up some of the problems with DVCS versus centralized
VCS (like subversion). Much further discussion occurs
On Sun, Dec 7, 2014 at 12:35 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sun, Dec 7, 2014 at 6:55 PM, to...@acm.org wrote:
The problem: A (mostly) text file with just a few normally non-text chars
which confuse fossil into thinking the whole file is binary.
There's an irony in there
On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote:
Sometimes we will make a check-in to trunk then later decide it doesn't
belong
On Thu, Sep 11, 2014 at 10:18 AM, John Long codeb...@inbox.lv wrote:
On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote:
On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams n...@cryptonector.com wrote:
git branch -D name
Eh, filesystems let you delete files. Unlike most filesystems
On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp d...@sqlite.org wrote:
On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams n...@cryptonector.com
wrote:
On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org
On the few cases when this has happened to me, I've moved goof into a
new
On Thu, Sep 11, 2014 at 11:18 AM, Richard Hipp d...@sqlite.org wrote:
On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams n...@cryptonector.com
wrote:
Nothing can really be made immutable, but you can detect mutation.
No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6
On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal sgb...@googlemail.com wrote:
No, he can't. Well, he can, but he will break the hashes of other records,
so any tamping will be noticed. Specifically, the Z- and R-cards detect any
sort of tampering.
Right. He can. If you've not pushed the
On Mon, Sep 1, 2014 at 10:29 AM, Stephan Beal sgb...@googlemail.com wrote:
Okay, more git bashing...
Seems like a lot of the complaints are the sorts of complaints you
would get about -say- laptops:
- it's easy to forget you left something on your laptop two flights
ago, when you had no
On Tue, Sep 2, 2014 at 6:47 PM, Richard Hipp d...@sqlite.org wrote:
(3) Create a new fossil bundle import command that imports a bundle as a
*private* branch.
Require a branch name as an argument and there will be no need to
think about branch name collisions.
It doesn't matter that the branch
On Sat, Jul 26, 2014 at 10:04 PM, Eric Rubin-Smith eas@gmail.com wrote:
Richard Hipp wrote:
Fossil can give you the ticket data as SQL. I think that is probably
about as portable as ticket data is going to get.
+1
... says the top SQL expert between here and the Romulan Neutral Zone.
On Mon, Jun 16, 2014 at 11:49 PM, B Harder brad.har...@gmail.com wrote:
Remember that the buffer is only one level deep, though. A subsequent ^W, ^K
, etc will clobber the previous contents.
Along lines of Stephan Beals method, I use : preceding the fossil command.
So:
$ : fossil ci -m
On Thursday, June 12, 2014, JR jr...@saintlyreverend.com wrote:
I will avoid the rant I had just written and simply say that I do not use
cmd.exe except where required. I use PowerShell exclusively, which makes
cmd.exe look like the ancient tool it is, and there are debates that
PowerShell
On Sun, Jun 8, 2014 at 7:15 PM, Ron Wilson ronw.m...@gmail.com wrote:
On Sat, Jun 7, 2014 at 8:37 PM, Nico Williams n...@cryptonector.com wrote:
The same is true for git, and Mercurial, and... It doesn't mean it
can't be done, just that the VCS has to know how to canonicalize the
file's
On Sat, Jun 7, 2014 at 1:32 PM, Stephan Beal sgb...@googlemail.com wrote:
It's unfortunately not a minor technical issue because of how fossil
calculates the hash for the whole contents of a repository for
...
The same is true for git, and Mercurial, and... It doesn't mean it
can't be done,
I should add that it's not always possible or desirable to test all
commits in a bundle that will be pushed together. A goal of breaking
up large commits into smaller ones is to make it easier to understand
and backport them, but an engineer working on a backport will have to
retest anyways.
On Saturday, June 7, 2014, Andy Bradford
amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org wrote:
Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500:
I should add that it's not always possible or desirable to test all
commits in a bundle that will be pushed together
On Wednesday, June 4, 2014, Alysson Gonçalves de Azevedo
agalys...@gmail.com javascript:_e(%7B%7D,'cvml','agalys...@gmail.com');
wrote:
I started to use fossil just today, but let me participate too :)
Everyday I have a list of tasks that I have to work on and when I finish,
I like to
On Thu, Jun 5, 2014 at 10:36 AM, B Harder brad.har...@gmail.com wrote:
drh Fossil allows you to commit a subset of files (by listing the
files on the fossil commit command line) but there is no mechanism
for committing a subset of lines within a single file.
That, and there _are_
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote:
foo.txt has changes A, B, C and D.
After each change the developer had the foresight to do a fossil stash
snapshot. Now the developer decides to put changes B and D into branch b-d
and keep changes A and C on the trunk:
On Thu, Jun 5, 2014 at 7:58 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote:
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote:
foo.txt has changes A, B, C and D.
After each change the developer had
On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo
agalys...@gmail.com wrote:
I'm not Nico, but allow me answer that as well.
When I was learning to use git, my teacher told me:
When you have a set of changes where a peace of code requires another
peace, you must commit all that
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com
wrote:
You're mixing things up :) Rebase is just a script around new branch
starting at given base, cherry-pick all the commits from the base
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com
wrote:
Mercurial too had heavy-duty branches only, then they added
bookmarks that are very similar to git branches. Since a bookmark
is just
On Wed, Jun 4, 2014 at 11:15 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Jun 4, 2014 at 6:03 PM, Nico Williams n...@cryptonector.com wrote:
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com
wrote:
Bookmarks. That's a nice idea, actually. Added to my TODO list.
i
On Wed, Jun 4, 2014 at 11:53 AM, B Harder brad.har...@gmail.com wrote:
Indeed, non-propagating tags are also checkout-able items.
What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?
In git, tags and branches are both very light-weight bookmark-like
On Wed, Jun 4, 2014 at 12:24 PM, Stephan Beal sgb...@googlemail.com wrote:
In the core, basically the only addition would be adding another block to
symbolic_name_to_rid(), which simply expands the ... part from bk:...
from the bookmark list, then runs that result through through
On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams n...@cryptonector.com wrote:
To be truly useful it has to be possible to [selectively] push/pull
bookmarks.
If that's the case then they really provide no benefits over
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com
wrote:
Right, the index is a very light-weight mechanism for giving the user
power in deciding what to commit. I.e., more fine-grained control
than choose
So git doesn't handle power failures so well... And Fossil's use of
SQL, and SQLite3 in particular, is awesome. But my colleagues and I
like git workflows, and anyways we have git repos we can't just
migrate to Fossil. The obvious idea is to use a git post-receive hook
to backup git to Fossil,
On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal sgb...@googlemail.com wrote:
My point being: at least some small percentage of round-trip timestamp
conversions will fail because Julian Days to not have a 1-to-1 mapping for
all millisecond-level ranges in use today.
Yes, though perhaps Fossil
On Tue, Jun 3, 2014 at 1:32 PM, Andy Bradford
amb-sendok-1404412362.ophlclhccgjkadkek...@bradfords.org wrote:
Thus said Nico Williams on Tue, 03 Jun 2014 11:42:44 -0500:
- the date (Fossil changes the timezone to +, that is, it loses
the timezone of the original).
Timestamps in Git
On Tue, Jun 3, 2014 at 2:03 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams n...@cryptonector.com wrote:
Being able to round-trip this way might allow more users to test-drive
Fossil.
It's not possible due to the limitations of round-tripping
On Tue, Jun 3, 2014 at 4:15 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams n...@cryptonector.com
wrote:
git rebase... doesn't remove commits from the repo. It only creates
new commits and then updates a branch's head to point to the newest
On Sun, Jun 1, 2014 at 5:56 AM, Dömötör Gulyás dognot...@gmail.com wrote:
On 1 June 2014 06:43, B Harder brad.har...@gmail.com wrote:
http://mikegerwitz.com/papers/git-horror-story
An interesting scenario, what is there to be learned from it for
fossil? Since fossil doesn't like history
On Mon, Feb 17, 2014 at 4:26 PM, Stephan Beal sgb...@googlemail.com wrote:
In which case I'd strongly urge that the best option here is to pick a
third party servlet engine based on its own criteria rather than
inventing yet another one --- they're harder than they look and there
are too many
On Fri, Feb 7, 2014 at 11:40 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Feb 7, 2014 at 6:15 PM, Ron Wilson ronw.m...@gmail.com wrote:
I am guessing this is a limitation of SQLite, which is designed to be
light. It would be interesting to see how Fossil would perform when
plugged in
On Thu, Jan 2, 2014 at 4:28 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Richard Hipp:
The silly requirement of some distributions that *everything* must be a
shared library irks me beyond words. I hate having to support
--disable-internal-sqlite, and I hate having to add silly work-arounds
On Thu, Jan 2, 2014 at 8:50 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Richard Hipp:
The silly requirement of some distributions that *everything* must be a
shared library irks me beyond words. [...]
Uhm, does POSIX
On Tue, May 28, 2013 at 10:25 AM, Richard Hipp d...@sqlite.org wrote:
If you forget to do it then, you can always visit a check-in after it is
committed and click on the Edit link to do things like revise the check-in
comment, update the check-in time, or move the check-in to a different
On Fri, Mar 29, 2013 at 6:55 AM, Richard Hipp d...@sqlite.org wrote:
Suppose I did write my own hosting system. What is is required for that.
(James, you have the most experience with this question, so your input is
especially encouraged!)
(1) Some means for people to create accounts
On Fri, Mar 29, 2013 at 6:55 AM, Richard Hipp d...@sqlite.org wrote:
What else is needed?
You'll also need:
- user and repo mgmt interfaces
If you grow you'll want a search facility (search multiple repos),
edit via browser UIs, ... Like github, basically.
Nico
--
On Thu, Jan 31, 2013 at 3:19 PM, K. Fossil user
ticketpersonnal-fos...@yahoo.fr wrote:
$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=auto \
--json \
--markdown
$ make
./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
applications requires at runtime the
On Thu, Jan 31, 2013 at 3:28 PM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user
ticketpersonnal-fos...@yahoo.fr wrote:
bld/shell.o: In function `find_home_dir':
./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
applications
https://chiselapp.com/user/nico/repository/nico
Two branches: rebase, and test-rebase.
This adds a --nocommit option to the fossil merge command that does...
what it sounds like it does: it applies the patch from a --cherrypick
commit and leaves that uncommitted.
I applied all the commits from
-
Hash: SHA1
On 12/31/2012 09:33 AM, Nico Williams wrote:
I'm very glad you mentioned this. I really would like git rebase (and
any equivalents in other VCSes) to add an empty commit whose message
contains: the old base commit hash, the new base commit has, and the
rebase recipe
There used to be a VCS called PRCS. It had no network support, but aside
from that it was awesome, partly because every file was assigned an
mnode, which was roughly an analog of inode numbers, and this allowed
wonderful rename functionality. The same approach might work equally well
for Fossil.
You could just compute throw away mnodes and just cache that. Fossil
already has a cache, no?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[Sorry to break threading, but I unsubscribed, then saw this in the
archives and re-subscribed just to answer, but I don't have the
Message-ID.]
On Sun, Dec 30, 2012, Joerg Sonnenberger wrote:
On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote:
I repeat: git rebase does
On Sun, Dec 30, 2012 at 9:41 PM, Mike Meyer m...@mired.org wrote:
Nico Williams n...@cryptonector.com 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
On Mon, Dec 31, 2012 at 12:01 PM, Steve Havelka yo...@q7.com wrote:
On 12/31/2012 06: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
Thanks Mike, I appreciate this.
BTW, I now have a pretty good idea of what fossil rebase would look
like; the discussion was a success, largely thanks to Joerg's insight.
I've also started looking at src/merge.c to have an idea of how to
implement a version of fossil merge --cherrypick that
On Sun, Dec 30, 2012 at 7:58 AM, Eric e...@deptj.eu wrote:
On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer m...@mired.org wrote:
Nico Williams n...@cryptonector.com wrote:
snip
Other things that can be redone in a rebase would include:
From what you've said, I believe that it's these *other
On Sat, Dec 29, 2012 at 8:53 AM, Eric e...@deptj.eu wrote:
On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com
wrote:
snip
Actually I agree with most of Mike Meyer's reply, but I wanted to pick
this paragraph apart:
How many times have you submitted a patch
On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
vi...@viric.name wrote:
(top post, due to the complexity of the previous post)
I've found many git-fans that are completely ashamed of how they develop. And
they would never make public how they commit things (how they use the VCS), so
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
vi...@viric.name wrote:
On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
And so on. Really. Large projects need order, they need process.
They need clean trees in official repos.
Without a way to clean history prior
On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org 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 require rewrites of history to do
so.
On Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell
vi...@viric.name wrote:
Ah sorry, I was only talking about my objections against git rebase. I don't
know the best way to implement a feature that allows creating 'new history' at
will (not destroying the old).
All I can imagine sounds
On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer m...@mired.org wrote:
Nico Williams n...@cryptonector.com wrote:
You missed my proposal that a fossil rebase operation always copy the
branch being rebased and rebase that copy. It was in my very first
post on this thread:
I didn't miss it. I asked
On Sat, Dec 29, 2012 at 10:49 PM, Michael Richter ttmrich...@gmail.com wrote:
I'm pretty sure that rebase or its equivalents will never be a part of
Fossil. Given that there are tools out there (like Git) that feature this
functionality that some (and I stress it's only some) users want,
On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 12:56, Nico Williams n...@cryptonector.com 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
On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 13:23, Nico Williams n...@cryptonector.com wrote:
A rebase operation takes a branch (typically the current one) and
two commits (oldbase and newbase) in the repository and then a)
computes
On Sun, Dec 30, 2012 at 12:09 AM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 14:00, Nico Williams n...@cryptonector.com wrote:
Because they want clean history.
This is precisely why I maintain that you're not going to see a rebase in
Fossil. Quoting from
http
On Sun, Dec 30, 2012 at 12:19 AM, Nico Williams n...@cryptonector.com wrote:
There's room for interpretation, and for persuasion.
That's one of the things that happen when we build religions: heresy.
Is this heresy? You can't say. Maybe not even D. Richard Hipp can
say. Unless I'm willing
On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 14:19, Nico Williams n...@cryptonector.com wrote:
There are differing philosophies here. Some say it is important to
present a clean, linear narrative of what took place - a narrative
I should also point out that in the Sun model once every one or two
bi-weekly mini-releases of the product gates the project gates would
have to catch up. Catching up in a way that leaves project commits
ahead of the product gate is effectively rebasing, which breaks child
gates, which is bad.
Rebase is one of teh killer features of git; the other killer features
of git are in Fossil already, but rebase is not. And fossil adds its
own killer features: built-in web service, JSON RESTful API, wiki and
tickets integrated (and versioned, natch).
How many times have you submitted a patch
IMO this should be resolved per-server configuration. Consider the
risk of XSS attacks: simply treating all comments as text/plain
automatically mitigates any past XSS attack attempts. Granted, XSS
attacks are not very likely given that few users can be expected to
have commit access...
I would
IIUC the main reason to want a DLL instead of having to spawn a new
process for every operation is iOS. I hear that the dearth of
excellent git (and other) SCM clients for iOS has to do with the
constrained nature of the run-time environment.
___
On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell
vi...@viric.name wrote:
I think that the git 'rebase' history rewriting could be stated different.
Maybe the graph could be altered with fossil cards, the same way commit logs
are
changed. Then, graph reworking would not imply history
On Fri, Aug 17, 2012 at 7:03 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sat, Aug 18, 2012 at 1:31 AM, Miles Fidelman mfidel...@meetinghouse.net
wrote:
Is there any kind of RESTful API for accessing Fossil repositories?
On Fri, Aug 17, 2012 at 11:24 PM, Stephan Beal sgb...@googlemail.com wrote:
Let's put it this way. To return 200 for a POST that actually failed
is very strange -- the response entity had better, at the very least,
not be cacheable if you'll do that.
Arg, I meant 201 code.
i would hope that
On Wed, Aug 15, 2012 at 11:26 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 15, 2012 at 12:22 PM, Nico Williams n...@cryptonector.com
wrote:
Is there any way to request that the changes from a commit be merged
into the workspace but not committed?
fossil merge will only merge changes
On Wed, Aug 15, 2012 at 5:48 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 15, 2012 at 12:03 AM, Nico Williams n...@cryptonector.com
wrote:
There is a cherrypick command? Oh, it's an option to the fossil merge
command. I had missed that entirely!
The --cherrypick option has been
Provocative Subject: line, I know.
But it's true, git-like rebase is not incompatible with Fossil's
principles *provided* that the result of a rebase is a new branch, or
provided that the branch being affected has no children (i.e., that
it's a private branch).
I use git a lot, and I like it. I
On Tue, Aug 14, 2012 at 8:28 PM, Matt Welland estifo...@gmail.com wrote:
I like the idea of cherry picking to a new branch. This would have nicely
solved a few problems I've faced. I suppose you can kind of do this now
using fossil cherrypick and manually creating the new branch but the
There
75 matches
Mail list logo
