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
On Mon, Jan 7, 2013 at 4:32 AM, Alaric Snell-Pym wrote:
> -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
> >>
-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
>> priv
On Jan 3, 2013 12:13 PM, "Richard Hipp" @
sqlite.org > wrote:
>
>
>
> On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym
>
@snell- pym.org.uk >
wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 12/31/2012 09:33 AM, Nico Williams wrote:
>>
>> > I'm very glad you mentioned this.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 3 Jan 2013 12:12:53 -0500
Richard Hipp 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 branch into trunk (or some other public br
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
On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym
wrote:
> -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
-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,
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 doesn
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
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 change
On 12/31/12 19:52, Doug Currie wrote:
> On Dec 31, 2012, at 1:29 PM, Nico Williams 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 wo
On Dec 31, 2012, at 1:29 PM, Nico Williams 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 by Fossil. While you
-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
On Mon, Dec 31, 2012 at 12:01 PM, Steve Havelka 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
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.
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 31 December 2012 04:41, Mike Meyer wrote:
>
>
> 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 re
On Sun, Dec 30, 2012 at 9:41 PM, Mike Meyer wrote:
> 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
[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 "manipu
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 only
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,
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 fr
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 woul
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 wrote:
> If I had written a ten-page post explaining in excruciating detail
>> what rebase is, why it matte
>
> 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
On Sun, Dec 30, 2012 at 7:58 AM, Eric wrote:
> On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer wrote:
>>
>> Nico Williams wrote:
>
>>> 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
On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer wrote:
>
> Nico Williams wrote:
>> 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 they get copied to a
> new branch. I
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
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. So
On Sun, 30 Dec 2012 14:40:27 +0800
Michael Richter
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 branches.
Private-branch
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 people understand "git rebase", and
>> -1.
>So is that a -1 to
On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter wrote:
> On 30 December 2012 14:19, Nico Williams 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 un
On 30 December 2012 14:19, Nico Williams 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 to present his
On Sun, Dec 30, 2012 at 12:19 AM, Nico Williams 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 fork fossil and do it
On Sun, Dec 30, 2012 at 12:09 AM, Michael Richter wrote:
> On 30 December 2012 14:00, Nico Williams 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://www.mail-archive.com/fossil-users@lists
On 30 December 2012 14:00, Nico Williams 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 they want cl
On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter wrote:
> On 30 December 2012 13:23, Nico Williams 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 br
On 30 December 2012 13:23, Nico Williams 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
> then b) creates a new line of commits that consists
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 destructive change to an exist
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 in
On 30 December 2012 13:02, 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 people understand "git rebase", an
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 destructive change to an existing branch?
>
I don't know. You won't explain it. "It's too mu
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 people understand "git rebase", and
>
> -1.
So is that a -1 to the attitude, the proposal,
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
On Sat, Dec 29, 2012 at 10:49 PM, Michael Richter 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, perhaps
> this follow
On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer wrote:
> Nico Williams 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 for clarification, for two
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
tha
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 require rewrites
>of history to
On Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell
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 like a lot
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
> 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
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 require rewrites of history to do
> so.
You missed m
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
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 pushing to
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 Williams wrote:
>
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
> 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 nev
On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
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
> they don't ac
On Sat, Dec 29, 2012 at 8:53 AM, Eric wrote:
> On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams
> wrote:
>
>
> 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
tl;dr: we agree that public history should not get rewritten. You
missed the point of when, where, and why I need rebase.
On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote:
> Nico Williams wrote:
>>Rebase is one of teh killer features of git.
>
> It certainly kills any interest I have in using
On Sat, 29 Dec 2012 19:55:28 +0400,
Konstantin Khomoutov wrote:
> On Sat, 29 Dec 2012 16:20:32 +0100
> LluÃs Batlle i Rossell wrote:
>
>> Top post due to...
> okay.
> The last three messages to this thread look somewhat alarming.
>
> In the first message of these, Mike Meyer, firs
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, 29 Dec 2012 10:24:05 -0600
Mike Meyer 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 "killer f
On Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell 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
> they don'
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 "killer feature"
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 wrote:
> You guys do really sound as a religious sect.
:) well, I think that everyone expects different jobs to be done by a VCS.
As for me, I like it to keep histor
On Sat, 29 Dec 2012 16:20:32 +0100
Lluís Batlle i Rossell 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 proceeded with a
fa
(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 Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams wrote:
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 git-style anyway.
Let's assume
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
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 to
http://facepalm.org
I feel stupid.
On 26 December 2012 02:23, Michael L. Barrow 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 "unknown
> c
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 varian
On 25 December 2012 07:12, 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 $DEVS
> >> do
> >> # Set up developers
> >> fs cap $dev
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 $DEVS
>> do
>> # Set up developers
>> fs ca
On Mon, Dec 24, 2012 at 3:39 PM, 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 $DEVS
>> do
>>
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 $DEVS
> do
> # Set up developers
> fs cap $dev v -R $REPO
> done
I know I'
On Tue, 18 Dec 2012 14:42:34 +0100, Gilles
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.
___
fossil-user
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.
>
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 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 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 use
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).
>
> http://en.wikiped
On 2012-12-18 22:50, j. v. d. hoff wrote:
On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer wrote:
well-balanced assessment.
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 o
On Tue, Dec 18, 2012 at 03:29:19PM -0600, Mike Meyer wrote:
> 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),
>
> Fossil: it's strong points are the built-in wiki and ticket trackin
Some random comments on using fossil in a large team, keeping the .fossil
file inside the repository etc.
I saw the fossil autosync methodology as being a nice bridge to make DSCM
approachable and usable for developers familiar with svn or DesignSync. I
still think it has helped but the resistance
On Tue, Dec 18, 2012 at 3:28 PM, j. v. d. hoff
wrote:
> On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp wrote:
>
>> On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer wrote:
>>
>>> I don't do that (I keep all my fossil repositories in ~/repos), so
>>> haven't paid close attention to the issues. The bi
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 01:04:19 +0100, Martin Gagnon wrote:
On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff
wrote:
On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp wrote:
On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer wrote:
I don't do that (I keep all my fossil repositories in ~/repos), so
On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff wrote:
> On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp wrote:
>
> On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer wrote:
>>
>> I don't do that (I keep all my fossil repositories in ~/repos), so
>>> haven't paid close attention to the issues. The bi
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 wrote:
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 co
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 Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp wrote:
On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer 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 itsel
On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer 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 rec
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 thin
On Tue, 18 Dec 2012 23:50:17 +0100, Jan Danielsson
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 fr
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 wo
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 repository. However, the fossil m
On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer wrote:
well-balanced assessment.
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 t
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
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#
99 matches
Mail list logo
