2015-04-14 21:11 GMT+02:00 Andy Bradford:
Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
Maybe more valuable would be to adapt the /leaves page, so people
searching forks have an easy way to do so.
I proposed this very thing a few days ago, and I think that this is
On Thu, Apr 16, 2015 at 1:38 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2015-04-14 21:11 GMT+02:00 Andy Bradford:
Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
Maybe more valuable would be to adapt the /leaves page, so people
searching forks have an easy way to do so.
2015-04-16 13:44 GMT+02:00 Matt Welland mattrwell...@gmail.com:
I'm confused by this. If the fork was merged to trunk it is no longer a fork
and should not be detected. Can you elaborate?
In fossil it is possible to merge a branch to trunk, but leave the
branch open. It could have been a
As the flurry of discussion of forks starts to ebb, it occurred to me
there is a conflict between how Fossil defines fork and how many open
source project define fork.
Fossil defines fork as an accidental, unintended branch in the commit
history.
But, to many in the open source community (and
Hi,
This is probably a trivial question, but I can't find a clear answer
in the documentation.
I have a repository at
http://kuu.se/fossil/b64.cgi/timeline
with two branches, trunk and c-stdin
In c-stdin, I created the file b64.c, which does not exist in trunk.
Some other files, created
Mercurial would call a Fossil fork a head[1].
-J
[1]: http://mercurial.selenic.com/wiki/MultipleHeads
On Thu, Apr 16, 2015 at 12:49 PM, Ron W ronw.m...@gmail.com wrote:
As the flurry of discussion of forks starts to ebb, it occurred to me
there is a conflict between how Fossil defines fork
On Thu, Apr 16, 2015 at 1:30 PM, James Moger james.mo...@gmail.com wrote:
Mercurial would call a Fossil fork a head[1].
-J
[1]: http://mercurial.selenic.com/wiki/MultipleHeads
That would be what Fossil calls a Leaf. I suppose, one could argue that,
in Fossil, a fork is a special case of a
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison sc...@casaderobison.com
wrote:
Some thoughts:
More seriously, the Wikipedia article on forking is probably worth a read:
http://en.wikipedia.org/wiki/Fork_(software_development)
I would claim that github is the odd man out here, having
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland mattrwell...@gmail.com
wrote:
On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2015-04-16 13:44 GMT+02:00 Matt Welland mattrwell...@gmail.com:
I'm confused by this. If the fork was merged to trunk it is no longer a
On Apr 16, 2015, at 10:47 AM, Johan Kuuse jo...@kuu.se wrote:
In c-stdin, I created the file b64.c
That’s not what this says:
http://kuu.se/fossil/b64.cgi/finfo?name=b64.c
I’ve done what you claim to have attempted, and if you had actually done this,
you would have seen something like
On Thu, Apr 16, 2015 at 1:27 PM, Ron W ronw.m...@gmail.com wrote:
On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
This document contains what Fossil considers a fork:
https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki
Yes. And the
On Thu, Apr 16, 2015 at 2:58 PM, Ron W ronw.m...@gmail.com wrote:
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison sc...@casaderobison.com
wrote:
Some thoughts:
More seriously, the Wikipedia article on forking is probably worth a
read: http://en.wikipedia.org/wiki/Fork_(software_development)
On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2015-04-16 13:44 GMT+02:00 Matt Welland mattrwell...@gmail.com:
I'm confused by this. If the fork was merged to trunk it is no longer a
fork
and should not be detected. Can you elaborate?
In fossil it is possible
On Apr 16, 2015, at 2:44 PM, Warren Young w...@etr-usa.com wrote:
On Apr 16, 2015, at 10:47 AM, Johan Kuuse jo...@kuu.se wrote:
In c-stdin, I created the file b64.c
That’s not what this says:
Also, notice that the checkin that claims to have created b64.c actually
modifies the copy
Thus said Ron W on Thu, 16 Apr 2015 15:27:38 -0400:
So I don't know of an alternative term already in use to suggest. Not
can I think of any other alternative term to suggest.
I don't know of an alternative either; perhaps a duplicate descendant
line.
Fossil simply defines it:
Having
Thus said Jan Nijtmans on Thu, 16 Apr 2015 10:38:17 +0200:
There's a fossil forks command on trunk now:
Thank you. Looks great.
Oops...
$ ./fossil new /tmp/new.fossil /dev/null
$ ./fossil forks -R /tmp/new.fossil
SQLITE_ERROR: no such table: vmerge
./fossil: no such table: vmerge
SELECT
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland mattrwell...@gmail.com
wrote:
Since these are effectively forks that have been resolved by merging is it
possible to detect them as such and not report them?
I think they probably could be reported as merged forks, but I'm not sure
that adds
On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
This document contains what Fossil considers a fork:
https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki
Yes. And the _connotation_ of the term fork within the Fossil community
is
From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford
amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote:
And a fork that ends in
Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600:
It is by design. Merging isn't always intuitive, and certainly there could
be a bug in it.
Perhaps like this one:
http://fossil.bradfords.org:8080/info/b1e9974a37c648fe
Why was that merge essentially a no-op?
I'm confused...
Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600:
Partly I think it is because your test case consists of a single file
of a single line, which means probably (I would think) every merge
resulted in a conflict that you had to resolve manually.
Yes, every merge is a conflict
On Thu, 16 Apr 2015 22:58:55 +0200, Ron W ronw.m...@gmail.com wrote:
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison sc...@casaderobison.com
wrote:
Some thoughts:
More seriously, the Wikipedia article on forking is probably worth a
read:
On Mon, Mar 2, 2015 at 6:30 AM, Richard Hipp d...@sqlite.org wrote:
Ben Pollack's essay at
http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/
succinctly points up some of the problems with DVCS versus centralized
VCS (like subversion). Much further discussion occurs
Thus said Ron W on Thu, 16 Apr 2015 21:04:12 -0400:
I disagree. While it might be the most common case, merging does not
explicitly state any intent beyond the merge itself, even a full
merge.
After one has merged a fork, does ``fossil merge'' report that there are
any more forks to
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
And a fork that ends in being merged is also no longer a fork.
I disagree. While it might be the most common case, merging does not
explicitly state any intent beyond the merge itself, even a full merge.
After all,
On Thu, Apr 16, 2015 at 8:15 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600:
It is by design. Merging isn't always intuitive, and certainly there
could
be a bug in it.
Perhaps like this one:
On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich s...@stef.rs wrote:
I'd argue this is not intuitive, especially to a new Fossil user.
Losing the file like this and not reporting at least as a warning seems
like a wrong design choice, to me.
I'd agree it is not intuitive, as it took some
On Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich s...@stef.rs wrote:
I think what happened is that the file got deleted in the trunk (by
another merge) and the OP expected it to be re-added by the last merge
because the file was there.
Is this by design? I would've expected it too.
It
Thus said Matt Welland on Thu, 16 Apr 2015 15:55:47 -0700:
I think merging a fork resolves then it and it is no longer a fork.
Only open forks represent potentially orphaned changes. Maybe we need
better terminology.
I think by definition it must be considered no longer a fork, however,
I'd argue this is not intuitive, especially to a new Fossil user. Losing the
file like this and not reporting at least as a warning seems like a wrong
design choice, to me.
I actually like flagging the file as a conflict, with auto-resolution being to
keep (re-add) the file. If this is tagged
On Thu, Apr 16, 2015 at 1:22 PM, Ron W ronw.m...@gmail.com wrote:
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland mattrwell...@gmail.com
wrote:
Since these are effectively forks that have been resolved by merging is
it possible to detect them as such and not report them?
I think they
Here's an easy way to reproduce it:
fossil new 1.fossil
fossil open 1.fossil
echo a.file
fossil addremove
fossil commit -m private --private
fossil clone 1.fossil 2.fossil
fossil pull -R 2.fossil --private
On Wed, Apr 15, 2015 at 6:26 PM, Mikhail Kryshen krys...@cs.petrsu.ru
wrote:
The
Thus said Ron W on Thu, 16 Apr 2015 12:49:43 -0400:
Unfortunately, I had no luck finding any better term for what Fossil
calls a fork. (My search-fu maybe off this morning.)
This document contains what Fossil considers a fork:
33 matches
Mail list logo
