Re: [fossil-users] Repairing trunk/timeline after a shun

On 5/17/16, John P. Rouillard wrote: > > Is there an expand(content) or something that I > could use? > Use the "content()" SQL function to decode the blobs. The argument is any symbolic name (like a prefix of the SHA1 hash). Example: SELECT content('trunk');

Re: [fossil-users] Repairing trunk/timeline after a shun

Hi Andy: In message <0dc19ff1-f9f1-67af-7119-62bf62462...@gmail.com>, Andy Goth writes: >On 5/14/2016 4:59 PM, John P. Rouillard wrote: >> fossil init shun.fossil >> mkdir shun >> cd shun >> fossil open ../shun.fossil >> echo 2 > 2 >> fossil addremove >> fossil ci -m "initial commit" >> echo 2a

Re: [fossil-users] Conversation with a CM guy

Hi Eric: In message , Eric Rubin-Smith writes: >> employability. > > >It takes less than a day to pick up git if you're used to fossil. I agree with you to an extent. There are some sharp edges in git that people seem to cut

Re: [fossil-users] Conversation with a CM guy

In message <4d41a0c9-37e8-1a0b-2120-99953b016...@gmail.com>, Andy Goth writes: >On 16 May 2016 15:34:02, John P. Rouillard wrote: >> I would like to see your document when you think it's ready to share. > >I can't, it's not mine to share. And even if I were willing to spill

Re: [fossil-users] Conversation with a CM guy

On May 17, 2016, at 12:25 PM, Ron W wrote: > > So far, none of the IDEs I've used seem to support VCS merges from within the > IDE. Visual Studio does, with Git: https://www.visualstudio.com/en-us/get-started/code/merging-with-squash

Re: [fossil-users] Conversation with a CM guy

> > > So far, none of the IDEs I've used seem to support VCS merges from within > the IDE. I've always had to go to the VCS itself (or, when using Hg or SVN > on Windows, TortoiseHg or TortoiseSVN), so lack of merging in libfossil > might not be a big issue for creating Fossil plug-ins for IDEs. >

Re: [fossil-users] Conversation with a CM guy

On Tue, May 17, 2016 at 2:22 PM, jungle Boogie wrote: > > If fossil had a more polished gui to move files and bring up boxes to > type in commit messages, it may be more popular too. As it is, most > fossil commands seem straight forward in my use cases. > Some of my

Re: [fossil-users] Conversation with a CM guy

On Tue, May 17, 2016 at 9:00 AM, Stephan Beal wrote: > On Tue, May 17, 2016 at 2:10 PM, Konstantin Khomoutov < > flatw...@users.sourceforge.net> wrote: >> >> And ways to integrate Fossil to popular solutions like MSVS and Visual >> Studio Code appear to be of increasing

Re: [fossil-users] Conversation with a CM guy

On 17 May 2016 at 05:10, Konstantin Khomoutov wrote: > Unfortunately, the major selling points of Subversion -- excellent > Windows support including (proprietary) server-side solution with GUI > configurator and TotroiseSVN -- do not exist for Fossil. Or at least

Re: [fossil-users] git rebase, and what it looks like in Fossil

On Tue, May 17, 2016 at 4:21 AM, Andy Goth wrote: > > So what would a Fossil analogue be? For simple cases, merge -baseline > root:branch does the trick. > > But if the branch being merged also includes merges from other branches > for the purpose of updating its

Re: [fossil-users] Conversation with a CM guy

On Tue, May 17, 2016 at 2:10 PM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > Unfortunately, the major selling points of Subversion -- excellent > Windows support including (proprietary) server-side solution with GUI > configurator and TotroiseSVN -- do not exist for Fossil.

Re: [fossil-users] Conversation with a CM guy

On 17/05/2016 15:10, Konstantin Khomoutov wrote: > I think its an overestimation. Don't forget that the landscape of > F/OSS VC systems was different back then. In reality, DVC systems > existing around year 2005 were either slow (Monotone, Darcs) or had > horrible UI (GNU Arch) so Torvalds had

Re: [fossil-users] Conversation with a CM guy

On Mon, 16 May 2016 23:06:59 -0500 Andy Goth wrote: > > He said he thinks he'll go with Git instead because that would give > > the engineers working under him more forward mobility when they > > eventually move on to other companies, whereas Fossil is unknown > > and

Re: [fossil-users] Suggestions for list of branches in web-UI

On Thu, May 12, 2016 at 12:48 AM, Marko Käning wrote: > 2) /brlist should NOT show closed branches (but could have a menu item for > that). On page /brlist?all the link “Open" leads straight away to /brlist > which is showing all existing branches, which is

[fossil-users] git rebase, and what it looks like in Fossil

As discussed previously, for some people rebase is the killer feature that makes git worthwhile. Yet we don't have it in Fossil, not with that name anyway. I admit my understanding of rebase is very limited, never having used git. But I gather it distills a branch down to the changes actually

Re: [fossil-users] Conversation with a CM guy

On Mon, 16 May 2016 23:30:16 -0500, Andy Goth wrote: > On 5/16/2016 11:24 PM, Stephan Beal wrote: > > It overwrote the whole drive with the word Hello. > > Or at least the first block, which is arguably the most important one > since it tends to contain tables critical to being able to actually

Re: [fossil-users] Conversation with a CM guy

On Tue, 17 May 2016 01:03:41 -0500, Andy Goth wrote: > > I wonder if a git-fossil (like git-svn) might be helpful for people? > > I don't know what git-svn is. It lets you manage your commits to Subversion using Git. Sort of a two-way bridge between SVN and Git, and related what you described in

Re: [fossil-users] Conversation with a CM guy

On Mon, 16 May 2016 23:06:59 -0500, Andy Goth wrote: > On 5/16/2016 1:17 PM, Andy Goth wrote: > > He said he thinks he'll go with Git instead because that would give the > > engineers working under him more forward mobility when they eventually > > move on to other companies, whereas Fossil is

Re: [fossil-users] Conversation with a CM guy

On 16 May 2016 15:34:02, John P. Rouillard wrote: > Andy Goth writes: >> He said he thinks he'll go with Git instead because that would give the >> engineers working under him more forward mobility when they eventually >> move on to other companies, > > Not totally