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
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.
> >
> > I pro
2015-04-16 13:44 GMT+02:00 Matt Welland :
> 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 partial merge, fossil has n
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 beforeha
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 communit
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 wrote:
> 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
On Thu, Apr 16, 2015 at 1:30 PM, James Moger 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 "leaf", bu
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
wrote:
> The problem reproduces with
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:
https://www.fossil-scm.org/index.html/doc/trunk/www/branching
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 2:41 PM, Andy Bradford
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 unintended/accidental commit to a pare
On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans
wrote:
> 2015-04-16 13:44 GMT+02:00 Matt Welland :
> > 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
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland
wrote:
>
>
> On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans
> wrote:
>
>> 2015-04-16 13:44 GMT+02:00 Matt Welland :
>> > 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
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland
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 value. What if someone
On Thu, Apr 16, 2015 at 1:27 PM, Ron W wrote:
> On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford
> 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 th
On Apr 16, 2015, at 10:47 AM, Johan Kuuse 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 ADDED_BY_MERGE
On Apr 16, 2015, at 2:44 PM, Warren Young wrote:
>
> On Apr 16, 2015, at 10:47 AM, Johan Kuuse 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 created on the trunk:
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 mo
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison
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 appropriated a
> term tha
On Thu, Apr 16, 2015 at 2:58 PM, Ron W wrote:
> On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison
> 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 githu
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.
Original Message
From: Warren Young
Sent: Friday, 17 April 2015 06:46
To: Fos
On Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich 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 is by d
On Thu, Apr 16, 2015 at 1:22 PM, Ron W wrote:
> On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland
> 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
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, howeve
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford
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, a merge doesn't automati
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
mailto:amb-fos...@bradfords.org>> wrote:
And a fork that ends in being merged is also no l
On Mon, Mar 2, 2015 at 6:30 AM, Richard Hipp wrote:
> Ben Pollack's essay at
> http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/
> succinctly points up some of the problems with DVCS versus centralized
> VCS (like subversion). Much further discussion occurs on the vari
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
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...
Than
On Thu, Apr 16, 2015 at 8:15 PM, Andy Bradford
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:
>
> http://fossil.bradfords.org:8080/info/b1e9974a3
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 tagge
On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich 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 hours
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 wrote:
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison
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
On Fri, 17 Apr 2015 06:56:13 +0200, Andy Bradford
wrote:
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
35 matches
Mail list logo
