-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2013 05:12 PM, Richard Hipp wrote:
Might that be a useful approach for Fossil, too?
If I understand you correctly, I believe this is what happens if you do
your lots of tiny commits into a --private branch, then merge that
private
On Mon, Jan 7, 2013 at 4:32 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2013 05:12 PM, Richard Hipp wrote:
Might that be a useful approach for Fossil, too?
If I understand you correctly, I believe this is what happens if
Hi!
On Sat, Dec 29, 2012 at 11:56 PM, Nico Williams wrote: I happen to
think that Fossil has a superior architecture and design. I'd like to
use Fossil, but I can't, and I've explained why. I've also explained
why I'm unlikely to be the only user who needs this one feature.
Thank you Nico for
-BEGIN PGP SIGNED MESSAGE-
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,
On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym
ala...@snell-pym.org.ukwrote:
-BEGIN PGP SIGNED MESSAGE-
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
Hello,
In my opinion, the private branch concept only works well for people
working in just one computer. In the every day more common case of
people developing in several computers (desktop, laptop, tablet, etc),
private branches do not adapt well to the situation. Probably the
solution could be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Jan 2013 12:12:53 -0500
Richard Hipp drh-czdrofg0bjidnm+yrof...@public.gmane.org wrote:
If I understand you correctly, I believe this is what happens if you
do your lots of tiny commits into a --private branch, then merge that
private
On Jan 3, 2013 12:13 PM, Richard Hipp drh d...@sqlite.org@d...@sqlite.org
sqlite.org d...@sqlite.org wrote:
On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym
alaricala...@snell-pym.org.uk
@snell- ala...@snell-pym.org.ukpym.org.uk ala...@snell-pym.org.uk
wrote:
-BEGIN PGP SIGNED
My understanding is that git rebase is used primarily to produce
patches to be applied onto a particular tag or checkin of a
destination repository, to give the same result as currently in the
source repository, but without requiring the destination to do a git
pull from the source repo, or to
[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 not
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 31 December 2012 04:41, 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 certainly
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.
--
Kind regards,
Jan Danielsson
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 to defend
yourself against such nonsense.
I agree with Jan. I also
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 to
-Original Message-
From: Steve Havelka
Sent: 12/31/2012 10:01
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
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
On Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote:
I haven't yet re-unsubscribed. Joerg's note added hope
Thank you for explaining rebase. It's not something I've ever needed to do, so
I was skeptical of its value, and even more skeptical that it would ever be
adopted
On 12/31/12 19:52, Doug Currie wrote:
On Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote:
I haven't yet re-unsubscribed. Joerg's note added hope
Thank you for explaining rebase. It's not something I've ever needed to do,
so I was skeptical of its value, and even more
I concur, the last month has seen a breakdown in the normally friendly
exchanges.
Might I suggest that we look on tomorrow as a new beginning - after all, we all
survived the end of the Mayan calendar :-)
This is open source software - so no one owes anyone any support.
If you want
On Mon, Dec 31, 2012 at 8:21 AM, Jan Danielsson
jan.m.daniels...@gmail.com 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.
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, 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 things*
that you want: an easy way to munge commits as
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
If I had written a ten-page post explaining in excruciating detail
what rebase is, why it matters, and how to adapt it to the Fossil
philosophy, who -but who!- would have read that first post?
I, for one, would have. I wouldn't necessarily have agreed, mind, because
the disagreement may be
I'd just like to add a link to a Git user who *doesn't* like rebasing:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
On 31 December 2012 07:26, Michael Richter ttmrich...@gmail.com wrote:
If I had written a ten-page post explaining in excruciating detail
what
On 12/30/2012 03:26 PM, Michael Richter wrote:
If I had written a ten-page post explaining in excruciating detail
what rebase is, why it matters, and how to adapt it to the Fossil
philosophy, who -but who!- would have read that first post?
I, for one, would have. I wouldn't
On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote:
I repeat: git rebase does not manipulate the pre-existing tree, it
does not destroy any history already in the tree. The only
destructive action that git rebase does is change the commit that a
branch _name_ points to, and from a
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 certainly did not
say I want git rebase in fossil and then watched the
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 to an upstream
Well, phrasing it like that says that you are thinking
(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
they don't accept other VCS that hasn't git rebasing capabilities.
I can't tell what
On Sat, 29 Dec 2012 16:20:32 +0100
Lluís Batlle i Rossell vi...@viric.name wrote:
Top post due to... okay.
The last three messages to this thread look somewhat alarming.
In the first message of these, Mike Meyer, first ruled out the whole
tool (Git) due to hating its optional feature and then
On Sat, Dec 29, 2012 at 07:55:28PM +0400, Konstantin Khomoutov wrote:
On Sat, 29 Dec 2012 16:20:32 +0100
Lluís Batlle i Rossell vi...@viric.name wrote:
sarcasmYou guys do really sound as a religious sect./sarcasm
:) well, I think that everyone expects different jobs to be done by a VCS.
As for
On Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net 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
On Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell vi...@viric.namewrote:
(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, 29 Dec 2012 10:24:05 -0600
Mike Meyer m...@mired.org 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
On Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net 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
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 to an
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 04:40:28PM -0600, Nico Williams wrote:
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
Nico Williams n...@cryptonector.com 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 m...@mired.org
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 to
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 05:37:35PM -0600, Nico Williams wrote:
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
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
Nico Williams n...@cryptonector.com wrote:
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
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, perhaps
this following question is to practical but … why not use Git, the tool
that
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,
Nico Williams n...@cryptonector.com 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:
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 a destructive change to an existing branch?
I don't know. You won't explain
On 30 December 2012 13:02, Nico Williams n...@cryptonector.com wrote:
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org 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 people
Michael Richter decía, en el mensaje Re: [fossil-users] Fossil vs.
Git/Mercurial/etc.? del Domingo, 30 de Diciembre de 2012 02:11:46:
There's use cases for every bizarre feature in every bizarre SCM (distributed
or otherwise) out there. Let's not turn Fossil into the C++ of DSCMs, shall
we
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 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 the set of commits that are in the branch since oldbase
then b) creates a new line
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 the
On 30 December 2012 14:00, Nico Williams n...@cryptonector.com wrote:
And why do they do this? I kinda/sorta get the mechanism. I just don't
see
the motivation. (And upstream maintainers insist upon this is not
motivation, it's just moving the question of motivation around.)
Because
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
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 to
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
that is easy to follow and easy to understand. Others say that it is
more important
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
that is
Nico Williams n...@cryptonector.com wrote:
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org 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 people understand git rebase, and
-1.
So
On Sun, 30 Dec 2012 14:40:27 +0800
Michael Richter ttmrich...@gmail.com
wrote:
I'd say the private branches pretty much eliminate your need for
rebasing entirely given what you've described as rebasing. Make your
mess in your private branches. Expose the pretty stuff in
non-private
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.
Nico Williams n...@cryptonector.com wrote:
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
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
Nico Williams n...@cryptonector.com 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
On 25 December 2012 07:12, Mike Meyer m...@mired.org wrote:
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
On 12/25/2012 12:44 AM, Michael Richter wrote:
This leaves me doubly confused. Neither of these command lines works
for me. There is no fossil cap I can see. (Fossil whines about
unknown command: cap.) And fossil new doesn't have that command
line that I can see. Is this some variant
http://facepalm.org
I feel stupid.
On 26 December 2012 02:23, Michael L. Barrow mlbar...@barrow.me wrote:
On 12/25/2012 12:44 AM, Michael Richter wrote:
This leaves me doubly confused. Neither of these command lines works for
me. There is no fossil cap I can see. (Fossil whines about
On 19 December 2012 07:33, Mike Meyer m...@mired.org wrote:
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
I
On Mon, Dec 24, 2012 at 3:39 PM, Michael Richter ttmrich...@gmail.com wrote:
On 19 December 2012 07:33, Mike Meyer m...@mired.org wrote:
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
Michael Richter ttmrich...@gmail.com wrote:
On 19 December 2012 07:33, Mike Meyer m...@mired.org wrote:
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
On Tue, 18 Dec 2012 14:42:34 +0100, Gilles
gilles.gana...@free.fr wrote:
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?
Thanks everyone for the great feedback.
On 2012-12-18 22:50, j. v. d. hoff wrote:
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
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 team (up to 20-30), and big teams
(thousands).
On Wed, Dec 19, 2012 at 12:06:05PM +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
On Wed, 19 Dec 2012 12:06:05 +0100
Remigiusz Modrzejewski l...@maxnet.org.pl 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
On Dec 19, 2012, at 19:56 , Mike Meyer wrote:
The big names have been created for huge teams, where people generally don't
want to be overwhelmed by tentative work done by others. Therefore they work
in isolation, issuing pull requests once the thing is done. Especially in
Git it's
On 12/19/12 22:57, Remigiusz Modrzejewski wrote:
It stands in stark contrast to Fossil's everybody has a copy of
everything.
Except for private branches. There's been some discussion about adding
more control over push/pull to fossil, but I don't believe it's
happened yet.
Private
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
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
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
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
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
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.
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
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?
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
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
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
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
91 matches
Mail list logo
