Re: [fossil-users] comparison with Git

[Michal Suchanek]

On 12 October 2012 00:21, Ron Wilson  wrote:
>
> I would think that rebasing would do the same number of merges, just
> that it automates those merges.
>

Yes, that's what rebasing is.

Also rebasing based development process keeps branches shallow and the
case with commits interleaved wildly does not really happen. Note that
you rebase against upstream that is independent of your branch so the
case when you merge upstream into your private branch does not really
happen. Upstream can at times include some of your commits which are
then eliminated from your branch on rebase because they are already
included in the upstream branch.

The thing what rebase gives you over single merge are readable patches
that are either accepted and included at the tip of upstream or can be
applied on top af a release tarball or can be basis for furthere
development.

With single merge you get a huge merge commit which can be used the
same way except it makes no sense on its own, can't be separated into
incremental changes that make sense, and when you base further
developmnet on top of it (eg. the merge was rejected by upstream) you
get those long branches that plug into ancient project history with
wildly interweaved commits.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Ron Wilson]

On 9/14/12, Michal Suchanek  wrote:
> On 14 September 2012 20:10, Jacek Cała  wrote:
>> I don't understand. Without rebase you just merge the other branch
>> (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts
>> and end up in the same point, ok with one more commit which is the
>> merge of F to Z.
>
> Except with a merge of F-Z you get a single commit which is often huge
> patch of no value on its own. To understand what it does you have to
> review the whole branch before the merge possibly with numerous
> intermediate merges.

What times did D, E and F take place relative to X, Y and Z? Simplest
case, merge X into F, creating X', then commit X' as child of F. Then
Y into X' and Z into Y', leaving a commit history of A, B, C, D, E, F,
X', Y', Z'.

Alternating case: Merge X into D, commit X'. Then Y into (E into X'),
commit Y'. Then Z into (F into Y'), commit Z'. Which is 2 extra
merges. I think this would be the worst case without involving
reordering.

For the given example of Z being a fix to X: Merge (Z into X) into D,
commit X'. Then Y into ((F into E) into X'), commit Y'. Still 2 extra
merges. (If you don't "squash" Z into X, then is same as the previous
case except swap Y and Z.)

I would think that rebasing would do the same number of merges, just
that it automates those merges.

I think a rebase script that uses Fossil would need to:

List "new" commits in time order

Allow user to alter order and specify any desired squashing.

Perform merges as needed, pausing as needed to allow user to resolve conflicts.

How close am I to what "git rebase" would do?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Mike Meyer]

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 (*cough* git *cough*) isn't linked with
>Eclipse, but probably uses a process API.
>
>But Fossil is not GPL. It would make perfect sense to link it wherever
>you'd like.
>
>For Git, it seems that it's primary implementation is a bit too messy
>for most big projects, so they simply reimplement it. Eclipse's
>implementation is called JGit. And it does provide a reasonably stable
>Java API, used by a few projects.

Yeah, the *reimplimented* git in order to avoid the language and license issues 
of using the git code directly. That pretty much kills the argument that having 
to invoke fossil as a command is to much work!

>On the other hand, Fossil's implementation is (apart from the regular
>forking) quite nice. I'd bet you a beer that once the JSON API is
>finished (in my already outlined understanding), it will be used by
>some useful projects.

No bet, because I agree with you. Except that I consider using modern 
concurrency technics a plus, not a minus.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Remigiusz Modrzejewski]

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 (*cough* git *cough*) isn't linked with Eclipse, but probably 
> uses a process API.

But Fossil is not GPL. It would make perfect sense to link it wherever you'd 
like.

For Git, it seems that it's primary implementation is a bit too messy for most 
big projects, so they simply reimplement it. Eclipse's implementation is called 
JGit. And it does provide a reasonably stable Java API, used by a few projects.

On the other hand, Fossil's implementation is (apart from the regular forking) 
quite nice. I'd bet you a beer that once the JSON API is finished (in my 
already outlined understanding), it will be used by some useful projects.


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Mike Meyer]

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
>> what it is designed to do, and how it is designed to be used, and
>then
>> either use it accordingly or find something else.
>> 
>> Of course success in extending or embedding depends on the level of
>> available skill in awk or Perl or Expect or whatever. Remember that
>the
>> target end-user for Fossil is a developer!
>
>Yeah, you pretty nailed it. A perfect explanation why Fossil's
>integrations into various IDE's, GUI front-ends and other integrations
>are so popular. I may be OK with CLI, but it already bit me a few
>times: I can not use Fossil in my day job, because there's no Eclipse
>plugin (apart from that, the team said "whatever", we're free to start
>new projects in whatever VCS that Eclipse supports).

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 (*cough* git *cough*) isn't linked with Eclipse, but probably 
uses a process API.

The mercurial folks have a Python API, but strongly recommend that you just run 
hg, as they work to keep that compatible between versions, and make no such 
effort with the Python API. It seems to have a plugin for most GUI IDEs.

>>> But don't say it's easy to extend by writing a separate client or
>ipc-ing
>>> to this one...
>> 
>> Why not, it's a perfectly acceptable technique.
>
>Acceptable, yes, in some circumstances. 

In *far* more circumstances than linking to a library is acceptable.

>But compare: open3 a process and parse the output (is it even
>guaranteed to be stable?) to a function call...

Well, an API - no matter how it's implemented - is only as stable as the 
developers make it. Whether or not you break an API when you upgrade the 
provider depends *far* more on the developers than whether they chose to 
provide it via an executable or a shared library.

And if you're going to compare them, compare the entire process:

One is - well, open the executable and parse the output. The other is: select a 
language that can be coerced into linking with the library you want to use, 
write or find a wrapper if it's required that will translate between calling 
conventions and data types, load the shared library and wrapper code, and *now* 
you can call your wrapper to get and convert the data. Oh, and if you want to 
let someone else use your plugin, you have to make sure all the licenses 
involved are compatible.

Nuts, after writing the Python wrapper for the perforce C++ library, I wound up 
rewriting it for our Windows group to use the p4 command instead of the 
library, because that was easier & cheaper than buying the C++ compiler used to 
build the Perforce Windows binary and porting Python to it. But it made our 
support scripts portable across Windows and Unix.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Remigiusz Modrzejewski]

On Oct 9, 2012, at 20:44 , Eric wrote:

> On Tue, 9 Oct 2012 12:19:59 +0200, Remigiusz Modrzejewski 
>  wrote:
>> 
>> But who would prevent a cow worker from using them?
> 
> Cow worker

Reference to the Dilbert comics... 

The idea is that, especially in corporate environments, you'll at some point 
end up working with people who'll be, in your eyes, highly defective. Unless 
you're always in exclusive control of hiring, you'd better think of mechanical 
ways to enforce your vision of the project.

>> 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
> what it is designed to do, and how it is designed to be used, and then
> either use it accordingly or find something else.
> 
> Of course success in extending or embedding depends on the level of
> available skill in awk or Perl or Expect or whatever. Remember that the
> target end-user for Fossil is a developer!

Yeah, you pretty nailed it. A perfect explanation why Fossil's integrations 
into various IDE's, GUI front-ends and other integrations are so popular. I may 
be OK with CLI, but it already bit me a few times: I can not use Fossil in my 
day job, because there's no Eclipse plugin (apart from that, the team said 
"whatever", we're free to start new projects in whatever VCS that Eclipse 
supports).

>> But don't say it's easy to extend by writing a separate client or ipc-ing
>> to this one...
> 
> Why not, it's a perfectly acceptable technique.

Acceptable, yes, in some circumstances. 

But compare: open3 a process and parse the output (is it even guaranteed to be 
stable?) to a function call...


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Eric]

On Tue, 9 Oct 2012 12:19:59 +0200, Remigiusz Modrzejewski  
wrote:
> 
> On Sep 14, 2012, at 21:02 , Bill Burdick wrote:
> 
> > On Fri, Sep 14, 2012 at 1:55 PM, Michael L. Barrow 
> > wrote:
> > 
> >> On 9/14/12 11:53 AM, Bill Burdick wrote:
> >> 
> >>> Rest assured that even if "weird" features like rebasing were to
> >>> "pollute" Fossil, no one would force you to use them :)
> 
> But who would prevent a cow worker from using them?

Cow worker

> >>> But the size and complexity of the resulting application which is known
> >>> for being well-engineered could suffer...
> > 
> > 
> > True for a generic, unknown feature, maybe, but not for rebasing, I think.
> > Rebasing could be implemented without changing the codebase at all,
> > just using the fossil command in a script.  A lot of extensions could be
> > done as external scripts -- both Fossil and Git are very easy to extend,
> > that way.  They both have good architectures; Fossil's is SQL and Git's is
> > NoSQL :).

Missed this a month ago, but still needs a comment I think.

Fossil's architecture is not SQL, see
http://www.fossil-scm.org/xfer/doc/trunk/www/theory1.wiki

And unless NoSQL simply means "not using SQL", then Git isn't it!

> 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
what it is designed to do, and how it is designed to be used, and then
either use it accordingly or find something else.

Of course success in extending or embedding depends on the level of
available skill in awk or Perl or Expect or whatever. Remember that the
target end-user for Fossil is a developer!

> But don't say it's easy to extend by writing a separate client or ipc-ing
> to this one...

Why not, it's a perfectly acceptable technique.

Eric
-- 
ms fnd in a lbry
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Remigiusz Modrzejewski]

On Oct 9, 2012, at 16:36 , Joe Mistachkin wrote:

> Remigiusz Modrzejewski wrote:
>> 
>> So, is it finally possible to script pre-/post- commit hooks?
>> 
> 
> More or less:
> 
>   
> http://www.fossil-scm.org/index.html/artifact?ci=trunk&filename=src/xfer.c&l
> n=1201-1205
> 
> The key is that these are actually post-transfer scripts.  It is up to the
> called script to determine how many commits, if any, have been done since
> it was last called.  I have a working proof-of-concept Tcl script on a
> private repository that does this and sends mail via SMTP if a commit is
> detected.  The real expressive power here comes from having Tcl enabled at
> compile-time (and via the runtime setting) and being able to seamlessly
> invoke it from TH1.

That's nice. I guess I'll try to use it in the following months (for continuous 
 integration). But it's still impossible to obtain policing with that. Like, 
refusing to receive a push if some commit was not properly signed. This would 
be a pretty useful thing that's long time possible in  the competing products. 
Thankfully I will not need that for a long time and hope Fossil gets it before 
that.

Kind regards,
Remigiusz Modrzejewski
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Joe Mistachkin]

Remigiusz Modrzejewski wrote:
>
> So, is it finally possible to script pre-/post- commit hooks?
> 

More or less:


http://www.fossil-scm.org/index.html/artifact?ci=trunk&filename=src/xfer.c&l
n=1201-1205

The key is that these are actually post-transfer scripts.  It is up to the
called script to determine how many commits, if any, have been done since
it was last called.  I have a working proof-of-concept Tcl script on a
private repository that does this and sends mail via SMTP if a commit is
detected.  The real expressive power here comes from having Tcl enabled at
compile-time (and via the runtime setting) and being able to seamlessly
invoke it from TH1.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Remigiusz Modrzejewski]

On Oct 9, 2012, at 13:30 , Joe Mistachkin wrote:

> 
> Remigiusz Modrzejewski wrote:
>> 
>> Actually... No. Fossil, with it's monolithic single-app design, is relatively
>> hard to both extend and embed.
>> 
> 
> I strongly disagree with this statement.  Fossil is very extensible in the
> classic Unix sense, by building command lines and parsing the resulting 
> output.

We both know how this compares to having an actual API...

> Also, much work has been done, by myself and others, to make Fossil
> extensible using Tcl.

So, is it finally possible to script pre-/post- commit hooks?

> Finally, Stephan Beal has done quiet a lot of work to make the JSON API a
> reality, which enables quite a few useful extensibility scenarios.

Yes, but his work would be much easier if it wasn't an afterthought. Plus, this 
is still a work in progress. Only once it is finished, and by that apart being 
functional I mean included in the official build and documentation, we can 
finally say that there is a Fossil API.

> She has not been ignored.  I have been assigned by Richard to help with
> integrating
> her work into Fossil and have been in direct contact with her.  Also, you
> may notice
> the "markdown" branch in the official repository as of October 3rd, 2012.

Oh, I missed that part. That's happy news to me :)


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Joe Mistachkin]

Remigiusz Modrzejewski wrote:
>
> Actually... No. Fossil, with it's monolithic single-app design, is
relatively
> hard to both extend and embed.
>

I strongly disagree with this statement.  Fossil is very extensible in the
classic
Unix sense, by building command lines and parsing the resulting output.

Also, much work has been done, by myself and others, to make Fossil
extensible using
Tcl.

Finally, Stephan Beal has done quiet a lot of work to make the JSON API a
reality,
which enables quite a few useful extensibility scenarios.

>
> Also, seeing how Natacha's attempts at providing a much-requested feature
were
> ignored, it can be hard to influence.
>

I very strongly disagree with this statement because I can prove it is
inaccurate.

She has not been ignored.  I have been assigned by Richard to help with
integrating
her work into Fossil and have been in direct contact with her.  Also, you
may notice
the "markdown" branch in the official repository as of October 3rd, 2012.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Alaric Snell-Pym]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/2012 11:19 AM, Remigiusz Modrzejewski wrote:

> Actually... No. Fossil, with it's monolithic single-app design, is relatively 
> hard to both extend and embed. Also, seeing how Natacha's attempts at 
> providing a much-requested feature were ignored, it can be hard to influence.

Is it time to fork Fossil? Richard has his own priorities, and if
there's enough people who'd like to see Fossil go in a different
direction, it would be perfectly honorouable for a fork that served
different priorities to form in an amicable manner. As much as possible
should be contributed to the original Fossil and then pulled into the
fork, but the fork can accept direct contributions that Original Fossil
won't.

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlB0AVgACgkQRgz/WHNxCGr2EQCfd0+wJw2Ox5kHNEzZuFJO96me
vEwAniXvrCjgaD5DgBVOEhhibnQIcOhD
=QgoL
-END PGP SIGNATURE-
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Remigiusz Modrzejewski]

On Sep 14, 2012, at 21:02 , Bill Burdick wrote:

> On Fri, Sep 14, 2012 at 1:55 PM, Michael L. Barrow wrote:
> 
>> On 9/14/12 11:53 AM, Bill Burdick wrote:
>> 
>>> Rest assured that even if "weird" features like rebasing were to
>>> "pollute" Fossil, no one would force you to use them :)

But who would prevent a cow worker from using them?

>>> But the size and complexity of the resulting application which is known
>> for being well-engineered could suffer...
> 
> 
> True for a generic, unknown feature, maybe, but not for rebasing, I think.
> Rebasing could be implemented without changing the codebase at all,
> just using the fossil command in a script.  A lot of extensions could be
> done as external scripts -- both Fossil and Git are very easy to extend,
> that way.  They both have good architectures; Fossil's is SQL and Git's is
> NoSQL :).

Actually... No. Fossil, with it's monolithic single-app design, is relatively 
hard to both extend and embed. Also, seeing how Natacha's attempts at providing 
a much-requested feature were ignored, it can be hard to influence. This can be 
seen as both curse and blessing, depending if what you need aligns with what 
is/will be there. 

But don't say it's easy to extend by writing a separate client or ipc-ing to 
this one...

Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Nico Williams]

On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell
 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 rewriting" (and thus
> history loss) as git does.

git rebase is one of git's various app killers.  And no, rebase need
not equal history re-writing.  When I rebase I almost always do it in
a branch new branch that starts with the same HEAD as the previous
one.  I use rebase for:

 - splitting commits
 - merging commits into one ("squash", not three-way merge)
 - amend commit messages
 - re-order commits

I do such things for either

a) cleanup (I want the master branch to be as clean as possible)
b) or in response to code review comments from an upstream I'll be
contributing commits to

Being able to do (b) is critical for some upstreams I contribute to.
Since I can't write perfect code the first time I absolutely need
rebase.  Again, rebase need not be seen as destructive: ideally git
rebase should require a new branch name argument and it should make
the new branch refer to the rebased contents while leaving the
previous branch alone.

Nico
--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

On Fri, Sep 14, 2012 at 1:55 PM, Michael L. Barrow wrote:

> On 9/14/12 11:53 AM, Bill Burdick wrote:
>
>> Rest assured that even if "weird" features like rebasing were to
>> "pollute" Fossil, no one would force you to use them :)
>>
>>  But the size and complexity of the resulting application which is known
> for being well-engineered could suffer...


True for a generic, unknown feature, maybe, but not for rebasing, I think.
 Rebasing could be implemented without changing the codebase at all,
just using the fossil command in a script.  A lot of extensions could be
done as external scripts -- both Fossil and Git are very easy to extend,
that way.  They both have good architectures; Fossil's is SQL and Git's is
NoSQL :).


Bill
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michael L. Barrow]

On 9/14/12 11:53 AM, Bill Burdick wrote:
Rest assured that even if "weird" features like rebasing were to 
"pollute" Fossil, no one would force you to use them :)


But the size and complexity of the resulting application which is known 
for being well-engineered could suffer...


--
michael at barrow dot me
+1.408.782.4249

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

Rest assured that even if "weird" features like rebasing were to "pollute"
Fossil, no one would force you to use them :)


On Fri, Sep 14, 2012 at 1:42 PM, Michael L. Barrow wrote:

>
> I'm a faithful Fossil user and I have enjoyed its "limitations" compared
> to Git because I consider them features. And pardon my commentary as I
> typically lurk on the list rather than provide ongoing input to the
> development.
>
> If Git does all of this fancy stuff already, why not just use Git? Why
> must the beauty and simplicity of Fossil be 'polluted' with this additional
> baggage?
>
> And, if you like some of what Fossil does and some of what Git does, then
> go and make a bastard stepchild of the two, but please do not advocate
> putting a bunch of "weird" stuff into Fossil!
>
> *phew* I feel better now that I've said that...
>
> :-)
>
> --
> michael at barrow dot me
> +1.408.782.4249
>
>
> __**_
> fossil-users mailing list
> fossil-users@lists.fossil-scm.**org 
> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michael L. Barrow]

I'm a faithful Fossil user and I have enjoyed its "limitations" compared 
to Git because I consider them features. And pardon my commentary as I 
typically lurk on the list rather than provide ongoing input to the 
development.


If Git does all of this fancy stuff already, why not just use Git? Why 
must the beauty and simplicity of Fossil be 'polluted' with this 
additional baggage?


And, if you like some of what Fossil does and some of what Git does, 
then go and make a bastard stepchild of the two, but please do not 
advocate putting a bunch of "weird" stuff into Fossil!


*phew* I feel better now that I've said that...

:-)

--
michael at barrow dot me
+1.408.782.4249

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

On 14 September 2012 20:10, Jacek Cała  wrote:
> 2012/9/14 Michal Suchanek :
>>
>> so you do a rebase so that your commits can be applied on top of F and
>> send then for review:
>>
>> A-B-C-D-E-F-X'-Y'-Z'
>>
>> If there are no conflicts between your changes and upstream this is
>> fine, otherwise you have to resolve them somehow, and upstream then
>> does not have to. They get nice linear history.
>
> I don't understand. Without rebase you just merge the other branch
> (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts
> and end up in the same point, ok with one more commit which is the
> merge of F to Z.

Except with a merge of F-Z you get a single commit which is often huge
patch of no value on its own. To understand what it does you have to
review the whole branch before the merge possibly with numerous
intermediate merges. With rebase you get patches that become part of
single, linear history. You can pick only some patches from the start
and when there are no interdependencies even just patches from the end
or middle, even outside of VCS on top of unpacked release tarball.

>
>> This leaves behind a hidden stump with the original X Y and Z commits
>> in git. In fossil the stump would remain and you would have to go out
>> of your way to hide it or not upload it during push.
>
> Is a short branch in the timeline such a bad thing really?

It just makes following the development history more difficult.

And when it does not pass the review for the first time it's not going
to be just a simple short branch.

Especially if you merge, then fix some bugs in stuff before the merge
and add fixes as new commits, then merge again, and repeat a few
times. Spaghetti.

>
>> Also if Z is really a fix for a bug in X which is not upstream yet you
>> might want to do an edit - swap Y and Z and squash X and Z so that the
>> upstream reviewer has easier job reviewing fewer patches.
>>
>> A-B-C-D-E-F-X'Z'-Y'
>
> That might be useful. But what if someone was tempted to do this for a
> fix to a patch that was done 100 commits earlier... Might become
> tricky I suppose.

Of course, that's why there is a distinction between 'public' and
'private' branches. You should state when a commit is part of an
'official' history and should no longer be edited.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Jacek Cała]

2012/9/14 Michal Suchanek :
>
> so you do a rebase so that your commits can be applied on top of F and
> send then for review:
>
> A-B-C-D-E-F-X'-Y'-Z'
>
> If there are no conflicts between your changes and upstream this is
> fine, otherwise you have to resolve them somehow, and upstream then
> does not have to. They get nice linear history.

I don't understand. Without rebase you just merge the other branch
(D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts
and end up in the same point, ok with one more commit which is the
merge of F to Z.

> This leaves behind a hidden stump with the original X Y and Z commits
> in git. In fossil the stump would remain and you would have to go out
> of your way to hide it or not upload it during push.

Is a short branch in the timeline such a bad thing really?

> Also if Z is really a fix for a bug in X which is not upstream yet you
> might want to do an edit - swap Y and Z and squash X and Z so that the
> upstream reviewer has easier job reviewing fewer patches.
>
> A-B-C-D-E-F-X'Z'-Y'

That might be useful. But what if someone was tempted to do this for a
fix to a patch that was done 100 commits earlier... Might become
tricky I suppose.

  Cheers,
  Jacek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[David Given]

Bill Burdick wrote:
[...]
> I think if you pull a rebased branch, you can get an error if the commit
> your branch is no longer in the branch history, at which point you have to
> decide what to do -- I think you can force the pull, if you want to.  If
> you made changes on the branch, you'd probably have to tag and merge to get
> it into the new version of the branch.

I can tell you from experience that yes, you do get an error, but no, it
is not an informative one. What actually seems to happen is that your
upstream apparently conflicts with itself.

It took me about a week to sort this out, which I eventually did by
nuking the whole repository and starting again. Luckily I hadn't checked
anything into it.

(What, bitter? Me?)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

On 14 September 2012 19:03, Jacek Cała  wrote:
> Thanks Bill for the explanation.
>
> I see private tags as the end result of 'squash' rather than 'edit'.
> If you have three commits A-B-C and decide to hide B, you will see
> A-C. And then diff between C-A will show combined commits B+C against
> A.
>
> Regarding 'edit' and 'reorder', while 'edit' could be useful, I see
> reordering as asking for troubles. I wonder if anyone uses it with
> shared repos?

Rebase is often used to bring patches up to date so that they can be
efortlessly pulled upstream.

You see a repository that has commits

A-B-C

you clone it and write some changes

A-B-C-X-Y-Z

but upstream has changed

A-B-C-D-E-F

so you do a rebase so that your commits can be applied on top of F and
send then for review:

A-B-C-D-E-F-X'-Y'-Z'

If there are no conflicts between your changes and upstream this is
fine, otherwise you have to resolve them somehow, and upstream then
does not have to. They get nice linear history.

This leaves behind a hidden stump with the original X Y and Z commits
in git. In fossil the stump would remain and you would have to go out
of your way to hide it or not upload it during push.

Also if Z is really a fix for a bug in X which is not upstream yet you
might want to do an edit - swap Y and Z and squash X and Z so that the
upstream reviewer has easier job reviewing fewer patches.

A-B-C-D-E-F-X'Z'-Y'

Again, you are left with a stump branch.

As the stumps thicken you can get quite some jungle.

Some filtering to exclude those stumps would help a lot.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Mike Meyer]

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, 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 live
>with all the things that caused you to decide not to use it.
>What you pull from them is up to you when you do the pull.

So you end up with two (or more) repos for the same project with different 
histories? And this is supposed to be better?

I think I'm better off choosing software designed to do the job I want done. 
Which in this case is to preserving history.

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

Commit objects in Git are like manifests in Fossil, their id is the hash of
their contents, so "squash", "split", and "reorder" all end up creating new
commit objects with different ids.  After a rebase, brach points to the new
most-recent commit produced.  I'm pretty sure the old commit objects are
still around and will only disappear if they aren't part of some other
branch and you do a gc.

I think if you pull a rebased branch, you can get an error if the commit
your branch is no longer in the branch history, at which point you have to
decide what to do -- I think you can force the pull, if you want to.  If
you made changes on the branch, you'd probably have to tag and merge to get
it into the new version of the branch.


On Fri, Sep 14, 2012 at 12:03 PM, Jacek Cała  wrote:

> Thanks Bill for the explanation.
>
> I see private tags as the end result of 'squash' rather than 'edit'.
> If you have three commits A-B-C and decide to hide B, you will see
> A-C. And then diff between C-A will show combined commits B+C against
> A.
>
> Regarding 'edit' and 'reorder', while 'edit' could be useful, I see
> reordering as asking for troubles. I wonder if anyone uses it with
> shared repos?
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Jacek Cała]

Thanks Bill for the explanation.

I see private tags as the end result of 'squash' rather than 'edit'.
If you have three commits A-B-C and decide to hide B, you will see
A-C. And then diff between C-A will show combined commits B+C against
A.

Regarding 'edit' and 'reorder', while 'edit' could be useful, I see
reordering as asking for troubles. I wonder if anyone uses it with
shared repos?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

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, 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 live with all the 
> things that caused you to decide not to use it.

What people publish for you to pull depends on them, not the VCS.

Even VCS like fossil that does not have native history editing can be coerced.

What you pull from them is up to you when you do the pull.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Mike Meyer]

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 live with all the things 
that caused you to decide not to use it.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

So, I think my description above shows why it's more versatile.  Rebasing
is a tool that reorders, combines, and splits commits.  A private tag might
be the end result of the editing.  Rebasing could be done in fossil, there
just isn't a tool to do it (and Git's rebase tools are pretty involved).
 You could produce a new branch/tag from it, instead of changing one and
that would be one way to rebase while preserving history.

Alternate timelines could also be a way to group tags/branches and bury the
ones that ended up not being important.


Bill


On Fri, Sep 14, 2012 at 11:11 AM, Jacek Cała  wrote:

> 2012/9/14 Bill Burdick :
> >
> > Private commit tags sound a little less versatile than Git rebasing.
>
>
> As said above, I don't really know how git rebasing works. Could you
> shed more light on why it is more versatile than the simple private
> tags?
>
>   Cheers,
>   Jacek
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Wes Freeman]

Rather than comparing Fossil to Git, I compare it to Github, the Git
hosting service I'm sure you're all aware of. They've come a long way
extending Git to make it easier to use and add the integrated issue
tracking/wiki that Fossil has that Git alone doesn't have. Github
additionally has some pretty nice looking Windows/Mac GUI desktop apps for
managing your local repositories, that automatically set up SSH keys, etc.,
and make the barrier to entry for Git trivial for those users (let's face
it, if you're a linux user, you should already know how to generate SSH
keys and do command line stuff, so I guess they didn't feel it was
necessary to provide a GUI so far).

The key difference between Github and Fossil, in my opinion, is that Github
is not open source and is quite expensive to use. I still use Fossil on
many personal projects, mostly because I run out of "private" repositories
on Github and am reluctant to increase my plan due to the monthly bill.
Github is a bit more shiny as a web application (I would hope so, given the
money they've got going in that they can spend on design/feature aspects).
Also, there's the fact that you typically provide your own hosting for
Fossil (although I know of the Chisel project--looks like that is coming
along as well; nice work James.), and the "forking" social aspect they sell
with.

One thing I like about Github that I wish Fossil had were email
notifications about things like commits and issues created/updated. I know
this was discussed years ago, and how it's difficult to set up because you
don't know which machine had the changes committed and who has already sent
emails out. But I imagine most people interested in this feature use Fossil
with a server hosting the "main" repository, so there should be a flag or
something you can send to fossil that would broadcast issue updates/code
commits, based on some configuration for an email server to send through.

As to the latest emails: The rebase commands come with many warnings about
how you shouldn't rewrite history except in your local copy, and people
have mixed opinions about that:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.htmlThe
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. I
somewhat prefer the autosyncing honest way that Fossil uses, but I can see
why some people would prefer to have one commit to look through while
merging changes in from someone, for example, which is the main use-case
for rebase, in my opinion.

Anyway, I don't mean to cause a heated discussion. Just throwing out some
more noise to this conversation, as one who uses both Fossil and Git on a
regular basis.

Wes

On Fri, Sep 14, 2012 at 12:00 PM, Jacek Cała  wrote:

> 2012/9/14 Bill Burdick :
> >
> > Sure, you could have named, alternate timelines and just choose which
> one to
> > make the default, each timeline forming a namespace for its branches and
> > tags and timelines could inherit from other timelines.  That way you
> could
> > have rabasing without losing history.
> >
>
> Hmmm... being pragmatic, who would like to have many timelines in the
> same project? IMHO that would make things quite complicated or at
> least unclear. Whereas the 'private' commit tags (which I mentioned
> above) would make things easier I believe; easier to implement and
> easier to use.
>
>   Cheers,
>   Jacek
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

I'm not an expert on rebasing -- I've only done it a couple times, but as
far as I know, rebasing changes the timeline of a branch (potentially
radically).  It lets you reorder commits, combine them together (squash
them), and break them into multiple commits (edit them).  I've only done
interactive rebasing, which opens an editor with something like this in it
(taken from this article,
http://git-scm.com/book/en/Git-Tools-Rewriting-History ), listing the
commits you want to edit from oldest to newest:

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

You then change the order of the lines and change whatever commands you
want from pick to edit or squash, save the file, and exit the editor,
allowing the rebase to continue.  Squash combines a commit with the one
before it.  Edit drops you to command line, where you can create multiple
commits and then returns you to the editor again with the new commits you
made inserted in the list.

Someone could certainly write a tool to do this in Fossil that creates a
new branch.


On Fri, Sep 14, 2012 at 11:12 AM, David Given  wrote:

> Bill Burdick wrote:
> [...]
> > Who would want to have that?  I think the Git community answers that.
> >  Anyone who wants to have a cleaner presentation of history than what
> > actually happened.  Being able to have a clean view without losing the
> > actual history sounds like a good trick, to me, and it would answer the
> > rebasing functionality gap that concerns some people.
>
> Would not the Fossil way to do this be to have two branches, one public
> and one development, and have periodic merges across from the
> development branch to the public branch? The public branch would have
> the 'clean' history, with single checkins containing lots of files
> representing complete features, but if anyone wants to see the details
> they can follow the merge into the development branch and see how the
> work was actually done.
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[David Given]

Bill Burdick wrote:
[...]
> Who would want to have that?  I think the Git community answers that.
>  Anyone who wants to have a cleaner presentation of history than what
> actually happened.  Being able to have a clean view without losing the
> actual history sounds like a good trick, to me, and it would answer the
> rebasing functionality gap that concerns some people.

Would not the Fossil way to do this be to have two branches, one public
and one development, and have periodic merges across from the
development branch to the public branch? The public branch would have
the 'clean' history, with single checkins containing lots of files
representing complete features, but if anyone wants to see the details
they can follow the merge into the development branch and see how the
work was actually done.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Jacek Cała]

2012/9/14 Bill Burdick :
>
> Private commit tags sound a little less versatile than Git rebasing.


As said above, I don't really know how git rebasing works. Could you
shed more light on why it is more versatile than the simple private
tags?

  Cheers,
  Jacek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

On Fri, Sep 14, 2012 at 11:00 AM, Jacek Cała  wrote:

> 2012/9/14 Bill Burdick :
> >
> > Sure, you could have named, alternate timelines and just choose which
> one to
> > make the default, each timeline forming a namespace for its branches and
> > tags and timelines could inherit from other timelines.  That way you
> could
> > have rabasing without losing history.
> >
>
> Hmmm... being pragmatic, who would like to have many timelines in the
> same project? IMHO that would make things quite complicated or at
> least unclear. Whereas the 'private' commit tags (which I mentioned
> above) would make things easier I believe; easier to implement and
> easier to use.
>

Private commit tags sound a little less versatile than Git rebasing.
 Multiple timelines is only one possibility, though.  You could do with
just 2, the "actual" and the "public."  The "public" could be a mutable
view on the "actual," which is immutable.  That brings up the question of
why there couldn't be more than just 2, of course  :).

Who would want to have that?  I think the Git community answers that.
 Anyone who wants to have a cleaner presentation of history than what
actually happened.  Being able to have a clean view without losing the
actual history sounds like a good trick, to me, and it would answer the
rebasing functionality gap that concerns some people.


Bill
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Jacek Cała]

2012/9/14 Bill Burdick :
>
> Sure, you could have named, alternate timelines and just choose which one to
> make the default, each timeline forming a namespace for its branches and
> tags and timelines could inherit from other timelines.  That way you could
> have rabasing without losing history.
>

Hmmm... being pragmatic, who would like to have many timelines in the
same project? IMHO that would make things quite complicated or at
least unclear. Whereas the 'private' commit tags (which I mentioned
above) would make things easier I believe; easier to implement and
easier to use.

  Cheers,
  Jacek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Bill Burdick]

On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell
wrote:

> On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote:
> > On 14 September 2012 16:57, Jacek Cała  wrote:
> > > Hi all,
> > >
> > > My two cents:
> > >
> > > I like phrase *commit jungle* and sometimes would like to revert some
> > > commits or "re-commit" things a bit different. I also suppose that it
> > > is not that rare when people commit something by mistake or something
> > > which has not been tested enough. On the other hand my gut feeling is
> > > that (apart from what was said before) changing history is just bad
> > > and should be avoided.
> >
> > The commit jungle the result of exactly that - reverting  some commits
> > or recommitting with the old commits staying around in many short
> > stumped branches.
>
> 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 rewriting" (and
> thus
> history loss) as git does.
>

Sure, you could have named, alternate timelines and just choose which one
to make the default, each timeline forming a namespace for its branches and
tags and timelines could inherit from other timelines.  That way you could
have rabasing without losing history.


Bill
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Remigiusz Modrzejewski]

On Sep 14, 2012, at 17:48 , Lluís Batlle i Rossell 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 rewriting" (and thus
> history loss) as git does.

That's a nice idea. But I guess it would make things a lot more complicated...


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Lluís Batlle i Rossell]

On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote:
> On 14 September 2012 16:57, Jacek Cała  wrote:
> > Hi all,
> >
> > My two cents:
> >
> > I like phrase *commit jungle* and sometimes would like to revert some
> > commits or "re-commit" things a bit different. I also suppose that it
> > is not that rare when people commit something by mistake or something
> > which has not been tested enough. On the other hand my gut feeling is
> > that (apart from what was said before) changing history is just bad
> > and should be avoided.
> 
> The commit jungle the result of exactly that - reverting  some commits
> or recommitting with the old commits staying around in many short
> stumped branches.

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 rewriting" (and thus
history loss) as git does.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

On 14 September 2012 16:57, Jacek Cała  wrote:
> Hi all,
>
> My two cents:
>
> I like phrase *commit jungle* and sometimes would like to revert some
> commits or "re-commit" things a bit different. I also suppose that it
> is not that rare when people commit something by mistake or something
> which has not been tested enough. On the other hand my gut feeling is
> that (apart from what was said before) changing history is just bad
> and should be avoided.

The commit jungle the result of exactly that - reverting  some commits
or recommitting with the old commits staying around in many short
stumped branches.

>
> Perhaps the tooling you are talking about is just a filtered commit
> view. I mean if fossil allowed users to attach a tag (e.g. "private")
> to commits to say that they aren't visible in the timeline by default,
> we could avoid the jungle and also keep exact history by giving users
> a "full view" option where everything is visible (as it is shown
> currently).
>
> Also the thing is that some commits tend to be more important than
> others (you usually tag somehow like version X.Y). But in this context
> it's perhaps better to say that some commits are much less important
> than others (e.g. correcting a spelling mistake in the comments). I
> think that the filtered view would allow to hide these.
>
> Michal would that be enough for you to match with the git rewriting
> option (which I'm not aware of)?

Indeed, it's about good  tools for filtering out unwanted commits and
good tutorial for using those tools. Not only for viewing but also for
pushing/pulling. Or perhaps good view filters would make pushing lots
of junk less of an issue.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Jacek Cała]

Hi all,

My two cents:

I like phrase *commit jungle* and sometimes would like to revert some
commits or "re-commit" things a bit different. I also suppose that it
is not that rare when people commit something by mistake or something
which has not been tested enough. On the other hand my gut feeling is
that (apart from what was said before) changing history is just bad
and should be avoided.

Perhaps the tooling you are talking about is just a filtered commit
view. I mean if fossil allowed users to attach a tag (e.g. "private")
to commits to say that they aren't visible in the timeline by default,
we could avoid the jungle and also keep exact history by giving users
a "full view" option where everything is visible (as it is shown
currently).

Also the thing is that some commits tend to be more important than
others (you usually tag somehow like version X.Y). But in this context
it's perhaps better to say that some commits are much less important
than others (e.g. correcting a spelling mistake in the comments). I
think that the filtered view would allow to hide these.

Michal would that be enough for you to match with the git rewriting
option (which I'm not aware of)?

  Cheers,
  Jacek


2012/9/14 Michal Suchanek :
> On 14 September 2012 15:52, Richard Hipp  wrote:
>>
>>
>> On Fri, Sep 14, 2012 at 9: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.
>>
>>
>> The exact preservation of history is considered "best practice" for
>> high-reliability and safety-critical systems.  Fossil, for example, was
>> designed to meet the VCS requirements of DO-178B level A.  (Ref:
>> http://en.wikipedia.org/wiki/DO-178B)
>>
>> You might not think that exact preservation of history is one of the primary
>> purposes of VCS, but not every project manager thinks exactly like you.
>>
>
> I don't think that's a bad goal. The failure I see is inadequate tools
> for working with the resulting commit jungle. And if you were really
> obstinate about that then fossil fails in that it does not record
> *every* change, it requires explicit commits.
>
> Thanks
>
> Michal
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

On 14 September 2012 15:52, Richard Hipp  wrote:
>
>
> On Fri, Sep 14, 2012 at 9: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.
>
>
> The exact preservation of history is considered "best practice" for
> high-reliability and safety-critical systems.  Fossil, for example, was
> designed to meet the VCS requirements of DO-178B level A.  (Ref:
> http://en.wikipedia.org/wiki/DO-178B)
>
> You might not think that exact preservation of history is one of the primary
> purposes of VCS, but not every project manager thinks exactly like you.
>

I don't think that's a bad goal. The failure I see is inadequate tools
for working with the resulting commit jungle. And if you were really
obstinate about that then fossil fails in that it does not record
*every* change, it requires explicit commits.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Mike Meyer]

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 using the VCS for. Given that I use the
VCS to capture an exact history of the change sets I thought were
worth committing, that *is* it's primary purpose.

> And the makes *sense* is the crucial part here. When you learn maths
> you often hear something like this theorem AB was first proven by XY
> using method CD but we will today prove it using a much shorter and
> easier to understand method EF. Similarly, when implementing a feature
> into a piece of software the real history and the logical changes that
> make sense and are easy to review are often quite different things.

True. And which of the two things you are interested in will depend on
*why* you're using the VCS. For me, the *real* history is the
important thing. Yeah, I may record having done something the wrong
way, but having a record of the wrong way and the results of doing it
that way is *also* important. Others can either skip doing that
exploration, or look through the history to see *why* that way is
wrong.

> With git you get powerful history rewriting commands. The drawback is
> that you have to be careful to not lose anything important in the
> rewriting.

Your view matches the common view of git users, which follow the Linux
project and treat the repository as part of the public face of the
project. If you look at things that way, not being able to edit the
repository history makes about as much sense as not being able to edit
the web site. I see the VCS as part of the internal project
documentation. Being allowed to edit it makes as much sense as editing
generated API documentation to change function signatures.

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Richard Hipp]

On Fri, Sep 14, 2012 at 9: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.
>

The exact preservation of history is considered "best practice" for
high-reliability and safety-critical systems.  Fossil, for example, was
designed to meet the VCS requirements of DO-178B level A.  (Ref:
http://en.wikipedia.org/wiki/DO-178B)

You might not think that exact preservation of history is one of the
primary purposes of VCS, but not every project manager thinks exactly like
you.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

Hello,

On 14 September 2012 14:43, Lluís Batlle i Rossell  wrote:
> On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
>> On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
>> flatw...@users.sourceforge.net> wrote:
>> Of all of the VCSes out there today, surely Git requires more daily
>> brain-cycles than any other.  I'm not talking about just the learning-curve
>> here.  Git requires more thought and attention even after you know it
>> well.  And that extra thought and attention that you devote toward
>> operating Git could be better spent working on your project.
>
> BTW, I've the impression that some people feel like they do something useful,
> just because they do something. That's how I see that some people enjoy using
> git. Like people who solves sudoku.
>

I find that git and hg require more thought in different areas. I
don't use fossil much but I would lump it together with hg here due to
the stress on immutable history.

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.

For start the VCS history is necessarily imperfect record because you
have only certain points in time recorded - the commits. What happens
in between might be equally or even more interesting and educational
but is not seen in the record.

Second the purpose of VCS is not to record exact history to the
tiniest detail but to record change(set)s to the code that are
somewhat self-contained and can be understood on their own. This may
be so that you can later go back and see what you did or so that you
can take these changesets and send them to an upstream/peer developer
for review, and it makes sense to them.

And the makes *sense* is the crucial part here. When you learn maths
you often hear something like this theorem AB was first proven by XY
using method CD but we will today prove it using a much shorter and
easier to understand method EF. Similarly, when implementing a feature
into a piece of software the real history and the logical changes that
make sense and are easy to review are often quite different things.

With git you get powerful history rewriting commands. The drawback is
that you have to be careful to not lose anything important in the
rewriting.

With hg and fossil rewriting is hard to non-existent and you end up
with a jungle of commits that is hard to navigate and without tools to
adequately manage such jungle.

So for me the cycles for managing source with git and with hg/fossil
are spent in different places but I would not say that one requires
less than the other. The hg manual recommends to use one I/O
repository to which you pull from usptream and push finished features
and development repositories(s) that contain the jungle of unfinished
features that you can just blow away when the feature is finished. Git
allows managing that in one repo but you need to remember doing
backups before attempting any drastic surgery on it. Not that you
don't need backups for other reasons, anyway.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Lluís Batlle i Rossell]

On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
> On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> Of all of the VCSes out there today, surely Git requires more daily
> brain-cycles than any other.  I'm not talking about just the learning-curve
> here.  Git requires more thought and attention even after you know it
> well.  And that extra thought and attention that you devote toward
> operating Git could be better spent working on your project.

BTW, I've the impression that some people feel like they do something useful,
just because they do something. That's how I see that some people enjoy using
git. Like people who solves sudoku.

Nevertheless, there are some kind of projects where git or monotone can have an
advantage; for example, there is more fine grained control of what you share and
what not of your graph, into a remote repository.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Lluís Batlle i Rossell]

On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
> On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> 
> >
> > On the other hand, Git is not *that* hard to learn basic concepts,
> > really.  And it has external tools providing fancy GUIs, if needed.
> >
> 
> My argument goes like this:  Every developer has a fixed number of "brain
> cycles" to use on any given day.  Some of this brain-energy must be
> expended for overhead, such as finding ones way to the coffee machine, or
> operating the version-control system (VCS).  The fewer brain-cycles one has
> to spend on the overhead functions, the more there are available for us in
> writing code.
> 
> The goal of Fossil is to require fewer brain-cycles.  Fossil isn't
> perfect.  I'm sure there are things that can be done so that it requires
> less effort.  But I believe it is better than monotone, bzr, or hg, and way
> better than git.
> 
> Of all of the VCSes out there today, surely Git requires more daily
> brain-cycles than any other.  I'm not talking about just the learning-curve
> here.  Git requires more thought and attention even after you know it
> well.  And that extra thought and attention that you devote toward
> operating Git could be better spent working on your project.

Interesting idea, this of brain cycles. :)

I also find git particularly difficult. In the case of having two checkouts in
two computers, it ends up scaling to 4 heads: local and remote head in each
computer. And all operations (merge, fetch, ...) work updating references
between those *4* heads, instead of 2.

I find that with two checkouts, I shouldn't need graph operations between 4
heads. For me, it means double work.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Richard Hipp]

On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

>
> On the other hand, Git is not *that* hard to learn basic concepts,
> really.  And it has external tools providing fancy GUIs, if needed.
>

My argument goes like this:  Every developer has a fixed number of "brain
cycles" to use on any given day.  Some of this brain-energy must be
expended for overhead, such as finding ones way to the coffee machine, or
operating the version-control system (VCS).  The fewer brain-cycles one has
to spend on the overhead functions, the more there are available for us in
writing code.

The goal of Fossil is to require fewer brain-cycles.  Fossil isn't
perfect.  I'm sure there are things that can be done so that it requires
less effort.  But I believe it is better than monotone, bzr, or hg, and way
better than git.

Of all of the VCSes out there today, surely Git requires more daily
brain-cycles than any other.  I'm not talking about just the learning-curve
here.  Git requires more thought and attention even after you know it
well.  And that extra thought and attention that you devote toward
operating Git could be better spent working on your project.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Konstantin Khomoutov]

On Thu, Sep 13, 2012 at 04:28:00PM -0700, Russ Paielli wrote:

> OK, so apparently I misunderstood in thinking that the "serverless,
> zero-administration" claim applies to Fossil. Thanks for the clarification.
> 
> If it were true, and if it distinguished Fossil from Git, I would have used
> it in my advocacy of Fossil.
I'd say that this aspect (tentative "zero-administration") would only
be of interest to persons who routinely perform the said administration
(possibly at their $dayjob), and users (in the sense "not system
administrators") are usually sold on other aspects of software.

> I am sold on the idea that Fossil is superior to Git on the basis of
> simplicity alone. Than again, I am currently a minimal Fossil user. Being
> an aero engineer rather than a developer per se, I'd rather not spend time
> learning Git. The problem, as I have said before here, is that Git seems to
> be the de facto standard for open-source software. So not knowing Git
> essentially shuts you out of most open source.
But as I understand, you're not a programmer (at least not a
"hard-core" type who just seek fun in learning the next big thing and
all that), so not learning Git to ride *this* wave looks to be perfectly
okay for you.

On the other hand, Git is not *that* hard to learn basic concepts,
really.  And it has external tools providing fancy GUIs, if needed.

> In addition, I feed slightly
> uncomfortable forcing someone who already knows Git to learn Fossil in
> order to work on my project. But maybe I shouldn't worry about that.
I think it highly depends on the person(s) you're considering as a
possible collaborator(s) for your project.  I'd say that learning Fossil
is not hard for anyone having decent knowledge of another DVCS system.
Another possible argument which might be used to convince someone is
that it's good to leave one's comfort zone from time to time; this
applies not only to social interactions but to programming languages and
software tools as well (and, I suppose, to many other fields I'm just
not familiar with).

You could also assess if your project would benefit from using
wiki/built-in documentation editor and issue tracker; if so, Fossil
might have a huge head start compared to other tools for you, and this
could be used when advocating its usage.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Russ Paielli]

OK, so apparently I misunderstood in thinking that the "serverless,
zero-administration" claim applies to Fossil. Thanks for the clarification.

If it were true, and if it distinguished Fossil from Git, I would have used
it in my advocacy of Fossil.

I am sold on the idea that Fossil is superior to Git on the basis of
simplicity alone. Than again, I am currently a minimal Fossil user. Being
an aero engineer rather than a developer per se, I'd rather not spend time
learning Git. The problem, as I have said before here, is that Git seems to
be the de facto standard for open-source software. So not knowing Git
essentially shuts you out of most open source. In addition, I feed slightly
uncomfortable forcing someone who already knows Git to learn Fossil in
order to work on my project. But maybe I shouldn't worry about that.

As I said before, it would be great if Fossil could interact with Git at a
push/pull level, but as I recall there are technical obstacles to that
idea. I am not trying to open up that can of worms again, although maybe I
just did.

--Russ P.

On Thu, Sep 13, 2012 at 4:36 AM, Richard Hipp  wrote:

>
>
> On Thu, Sep 13, 2012 at 3:13 AM, Russ Paielli wrote:
>
>> I recall reading somewhere (can't seem to find it at the moment) that
>> fossil is a "serverless, zero-administration" program. Is that true of git
>> also? Thanks.
>
>
> We make that claim about the SQLite database engine.  See
>
> http://www.sqlite.org/about.html
>
> Fossil is the DVCS used to manages the SQLite sources, and Fossil is built
> on top of SQLite.  The homepages for Fossil and SQLite are hosted on the
> same machine.  But Fossil and SQLite are not the same thing.
>
>
>>
>> --Russ P.
>>
>> --
>> http://RussP.us
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
http://RussP.us
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Richard Hipp]

On Thu, Sep 13, 2012 at 3:13 AM, Russ Paielli wrote:

> I recall reading somewhere (can't seem to find it at the moment) that
> fossil is a "serverless, zero-administration" program. Is that true of git
> also? Thanks.


We make that claim about the SQLite database engine.  See

http://www.sqlite.org/about.html

Fossil is the DVCS used to manages the SQLite sources, and Fossil is built
on top of SQLite.  The homepages for Fossil and SQLite are hosted on the
same machine.  But Fossil and SQLite are not the same thing.


>
> --Russ P.
>
> --
> http://RussP.us
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Konstantin Khomoutov]

On Thu, 13 Sep 2012 00:13:43 -0700
Russ Paielli  wrote:

> I recall reading somewhere (can't seem to find it at the moment) that
> fossil is a "serverless, zero-administration" program. Is that true
> of git also? Thanks.

Depends on how you define "serverless".
Any distributed SCM (Fossil and Git included) is specifically designed
to keep all the repository history on a local machine, so if by
"serverless" you mean that an SCM do not need to contact a server to
record a commit (or fetch history log or whatever else) then yes, both
Fossil and Git are serverless, and so does every other DVCS out there.

As to "zero-administration", this sounds more like a flame bite rather
than a technical consideration: any DVCS system requires certain amount
of administration around it.  This might possibly refer to the fact
Fossil is self-hosting -- you can transfer its binary to a machine, run
it and it will serve the specified repository (or a set of them) all by
itself as it includes a built-in web-server which is used for both web
UI and data pushes/pulls.

The real aspect in which Fossil shines, is that it provides a turn-key
*integrated* solution consisting of an SCM (obviously), wiki, bug
tracker, project documentation editing, and user database with access
controls, all accessible/configurable via web UI, and all that is
provided by a single 1.2M binary which only depends on libc, zlib and
openssl (optionally).  This really rocks for certain applications.

You could read this classical post by Zed Shaw [1] explaining it all.

1. http://sheddingbikes.com/posts/1276624594.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] comparison with Git

[Russ Paielli]

I recall reading somewhere (can't seem to find it at the moment) that
fossil is a "serverless, zero-administration" program. Is that true of git
also? Thanks.

--Russ P.

-- 
http://RussP.us
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users