[fossil-users] Fossil versus ClearCase performance

[Andy Goth]

I have a hybrid Fossil/ClearCase checkout directory with ClearCase driving
and Fossil synchronizing, like I described earlier on this list.

"f changes" takes 0.061 seconds to complete.

The ClearCase equivalent is to get a list of checked-out (editable) files
and a list of hijacked (edited without permission) files. The commands is:

cl ls -l -r | egrep 'hijacked|CHECKEDOUT'

This takes 14.694 seconds. That's over 240 times as long as Fossil, just to
see what I've changed.

Maybe our network is slow, maybe our server is misconfigured. But I'll note
that Fossil doesn't care about either of these possibilities when looking
for changes.

By the way, "f changes -sha1sum" takes 0.526 seconds, and "f extras" 0.095.
Number of files? 7445.

This is ClearCase 7.1.2.19. No NFS involved.

Actually, asking which files I've checked out isn't the same as getting a
list of files I've actually modified, merely a list of what I declared I
intend to modify. I don't even know a good one-liner to get the list of
non-hijacked changes.
___
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] Quotes (was: git rebase, and what it looks like in Fossil)

[Andy Goth]

Not sure it's fair to include my quote when I've never once actually used
git, but I appreciate your vote.
On May 18, 2016 09:29, "Richie Adler"  wrote:

> El 18/05/2016 a las 10:56, Andy Goth escribió:
> > [...] the git model may have compromised its users' thought processes to
> > the point where they don't realize they're missing anything, basically a
> > combination of Sapir-Whorf and Stockholm Syndrome.
>
> I vote this to be added to the list of quotes about Git :)
>
>
> ___
> 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] Sing a song of praise for git {retch}

[Scott Robison]

On Wed, May 18, 2016 at 2:04 PM, Warren Young  wrote:

> On May 18, 2016, at 1:31 PM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> >
> > The fact there are morons among your technical staff is unfortunate
> > (and I sympathize you on this) but this has nothing to do with Git.
>
> From a “rebase doesn’t kill repositories, people kill repositories”
> standpoint, I suppose you are correct.
>
> Nevertheless, it’s been pretty thoroughly argued on this list that the
> arguments in favor of rebase are all either esoteric or wrong, so unless
> you really do have one of those esoteric needs, it’s best to use an SCM
> that doesn’t let you do that.
>
> I will disagree with your characterization of Scott’s coworkers as morons,
> however.  They’re likely technically competent, but they have ignored the
> Spider Man principle: with great power comes great responsibility.  When
> you draw rebase from your git holster in anger, you’d best be prepared to
> take responsibility for everything that happens to all of the clones of
> that repository until they’ve all git-pulled.
>
> I find myself without a good reason to rebase, so I am relieved that I do
> not have to take responsibility for my [mis]uses of it.
>

And they are taking responsibility. The frustrating part for me is that
this is not the first time this has happened. Well, that, and that a
telecommute day turned into a day in the office because I needed to
coordinate with people more closely than I could remotely.

-- 
Scott Robison
___
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] Sing a song of praise for git {retch}

[Scott Robison]

On Wed, May 18, 2016 at 1:31 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Wed, 18 May 2016 13:12:30 -0600
> Scott Robison  wrote:
>
> [...]
> > Yes, I dislike git (though TortoiseGit makes it a lot more
> > tolerable). I don't blame guns when people get shot, or knives when
> > people get stabbed, or cars or alcohol when someone dies in a drunk
> > driving accident. The fact that git has a rebase command doesn't
> > appeal to me, but if other people want to "fix" their history before
> > publishing it, fine. But once it is published leave it the hell alone!
> [...]
>
> When you record a commit, you might be introducing an error in the
> project.  So let's not have the "commit" feature in our VC tools.
>
> The fact there are morons among your technical staff is unfortunate
> (and I sympathize you on this) but this has nothing to do with Git.
>

I pretty much said as much above if you read my email completely. I don't
blame tools when people use them wrong. I still don't like this tool, but I
have definitely been inconvenienced by someone else's improper use of the
tool. Thus I want to take the tool away from them.

I've never ever once had a problem with fossil sync or fossil pull when I
have no uncommitted changes. If I have uncommitted changes, merge may fail.

Using git is like travelling through the multiverse. I'm on Earth-1 and I
clone and checkout version 42 of some repo onto my laptop. The next time I
try to pull updates, I get an error because somehow I'm now on Earth-2
where version 42 never existed.

-- 
Scott Robison
___
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] Sing a song of praise for git {retch}

[Warren Young]

On May 18, 2016, at 1:31 PM, Konstantin Khomoutov 
 wrote:
> 
> The fact there are morons among your technical staff is unfortunate
> (and I sympathize you on this) but this has nothing to do with Git.

From a “rebase doesn’t kill repositories, people kill repositories” standpoint, 
I suppose you are correct.

Nevertheless, it’s been pretty thoroughly argued on this list that the 
arguments in favor of rebase are all either esoteric or wrong, so unless you 
really do have one of those esoteric needs, it’s best to use an SCM that 
doesn’t let you do that.

I will disagree with your characterization of Scott’s coworkers as morons, 
however.  They’re likely technically competent, but they have ignored the 
Spider Man principle: with great power comes great responsibility.  When you 
draw rebase from your git holster in anger, you’d best be prepared to take 
responsibility for everything that happens to all of the clones of that 
repository until they’ve all git-pulled.

I find myself without a good reason to rebase, so I am relieved that I do not 
have to take responsibility for my [mis]uses of it.
___
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] Sing a song of praise for git {retch}

[Konstantin Khomoutov]

On Wed, 18 May 2016 13:12:30 -0600
Scott Robison  wrote:

[...]
> Yes, I dislike git (though TortoiseGit makes it a lot more
> tolerable). I don't blame guns when people get shot, or knives when
> people get stabbed, or cars or alcohol when someone dies in a drunk
> driving accident. The fact that git has a rebase command doesn't
> appeal to me, but if other people want to "fix" their history before
> publishing it, fine. But once it is published leave it the hell alone!
[...]

When you record a commit, you might be introducing an error in the
project.  So let's not have the "commit" feature in our VC tools.

The fact there are morons among your technical staff is unfortunate
(and I sympathize you on this) but this has nothing to do with Git.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Sing a song of praise for git {retch}

[Scott Robison]

I had a couple of trouble tickets wind up in my queue at work. We use git.
One of the dependent projects, which I use in a read only fashion, was
apparently out of date, so I did a git pull to get up to date. Lo and
behold, git pull refuses to work because I have uncommitted changes. Except
I never make changes to this project.

Email to dept: "I’m trying to pull SDK and it is complaining that I have
uncommitted changes. I’m sure I’ve never edited SDK. Is this a situation
where someone rebased after I last updated and thus I’m out of sync? Should
I just delete and reclone?"

Reply: "There was a rebase recently. Delete and clone again."

Me: "Why would we rebase published work? This makes no sense."

Response: "Because sometimes it makes sense to do that."

{slamming head on desk}


Yes, I dislike git (though TortoiseGit makes it a lot more tolerable). I
don't blame guns when people get shot, or knives when people get stabbed,
or cars or alcohol when someone dies in a drunk driving accident. The fact
that git has a rebase command doesn't appeal to me, but if other people
want to "fix" their history before publishing it, fine. But once it is
published leave it the hell alone!


I should not have to issue:

git checkout -- .

git reset --hard HEAD

git pull


Because it was convenient for one person on a team of dozens of people to
rewrite history, thus inconveniencing the many for the sake of the one.


I know you have number choices of rants to read online. I and the entire
Scott Robison team would like to thank you for choosing us over the
competition.

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

[fossil-users] Automatic Ticket-commit tagging

[Steve Schow]

I am getting tired of having to copy and paste the ticket uid into my commit 
comments in order to automatically link multiple commits to a single ticket.  
The ability to go to a ticket and see the list of checkins associate with it is 
very important to me, but the manual overhead to make it so, is cumbersome.  

I’m going to try to make some kind of wrapper script to my commit command that 
can do this for me, but before I embark I am wondering if anyone has thought of 
any good ways to do this, perhaps using TH1 in the repo or something….or 
perhaps using the checkout DB in some way to keep track of what the current 
ticket is.

Any creative ideas are welcome at this point…




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

[fossil-users] Quotes (was: git rebase, and what it looks like in Fossil)

[Richie Adler]

El 18/05/2016 a las 10:56, Andy Goth escribió:
> [...] the git model may have compromised its users' thought processes to
> the point where they don't realize they're missing anything, basically a
> combination of Sapir-Whorf and Stockholm Syndrome.

I vote this to be added to the list of quotes about Git :)


___
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] git rebase, and what it looks like in Fossil

[Andy Goth]

On 5/17/2016 12:54 PM, Ron W wrote:
> 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 baseline, those merges need
>> to be backed out as well.
>>
>> Yet there could be other merges into the branch that need to be kept
>> since they're coming from other branches that themselves will never
>> be merged into the target of the first merge.
>>
>> How to distinguish between the last two cases?
> 
> I don't think git rebase automates this. As best I've been able to
> discern, it automates certain types of sequential merges to help in
> relocating a branch from one baseline to another. The hard work of
> determining what to back out and/or cherry pick still requires a lot of
> human direction.

That's actually good news.  It means I don't have to feel bad about not
having a foolproof heuristic.  (Contradiction in terms, I know.)

I'll have to think about how to mechanize the user specifying which
contributors to keep and which to disregard as noise.

One consideration is what the default behavior should be.  When another
branch was merged with -integrate, that's a pretty good indication it
should be included.  However, half the time I forget to use -integrate
and instead close the branch manually sometime later.  So the test
should be whether a close event happened between the merge and the next
(if any) check-in on the branch (could have been reopened).  Backing up
a step, I think this automatic behavior should be optional, though the
question is whether the option would be to enable it or disable it.

The next consideration is whether or not the list of inclusions and
exclusions should be finalized when the merge command is run.  They
would be command-line options, of course, but I'm wondering if there
should also be commands that can be run later to amend the list of
inclusions and exclusions.  The trouble with that is the success of the
result may depend on the order of operations, so each amendment might
trigger backing out and rerunning the entire merge, which will wreak
havoc with any conflicts that were in the process of being resolved,
including conflicts with edits that were made prior to commanding the
merge in the first place.  Maybe undo is good enough, but I don't know.

> The core devs never said anything about my changes being only single
> commits.

Possibly git limitations meant they couldn't tell the difference, haha.
Actually I mean that two ways.  One, git might not have made it clear
one way or the other, or perhaps it even loses track of the distinction.
Two, the git model may have compromised its users' thought processes to
the point where they don't realize they're missing anything, basically a
combination of Sapir-Whorf and Stockholm Syndrome.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Repairing trunk/timeline after a shun

[Andy Goth]

On 5/17/2016 9:01 PM, John P. Rouillard wrote:
> Would it be worth mentioning that shunning a commit does not shun the
> artifacts checked in during that commit?

The shun page should give more information about its effective use.

> Is there any way to identify and remove these unconnected artifacts?

They show as "unknown" in the list of artifacts (/bloblist).  I'd have
to review the code for the exact reasons for this annotation.  I see
lots of unknowns in Fossil's own list of artifacts, by the way, so it
could also be there are deficiencies in the artifact classification logic.

Here's one case: http://fossil-scm.org/index.html/info/e791da28f3fbc43f

And another: http://fossil-scm.org/index.html/info/f39e8905c78826c5

For the most part, it looks like "unknown" means a control artifact (not
a manifest).  We should fix that, probably also change "unknown" to
"orphaned" or "unreferenced" or some such.  And then we should add a
page listing such unreferenced artifacts, or update /bloblist to have
filter and/or sort options.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Conversation with a CM guy

[Piotr Orzechowski]

And so does IntelliJ: 
https://www.jetbrains.com/help/idea/2016.1/merging-deleting-and-comparing-branches.html#d1537633e130.
Regards,
Orzech
Dnia 17 maja 2016 21:01 Warren Young w...@etr-usa.com napisał(a):
On May 17, 2016, at 12:25 PM, Ron W ronw.m...@gmail.com 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
___
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