[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Moving pkgsrc-wip away from SourceForge
Benny Siegert <bsiegert%gmail.com@localhost> writes:
> On Mon, Jul 13, 2015 at 3:14 PM, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
>> If you read your original mail again, you'll see that it is written in a
>> form that suggests that consensus has been reached. It is written in a
>> form as to notify others rather than in a form to start a discussion.
> Yes, I was in fact reporting the consensus of the people around the table.
>> I don't see rationale neither for VCS change nor for hoster change,
>> and I'd like to see it.
> (that was in 2013!)
> In short: you do not want to be hosted by a malware distributor.
And it applies to pkgsrc-wip how?
> VCS: every discussion on tech-repository, ever. Literally. Plus many
> of the private ones that you have access to as a dev. Look, I don't
> want to rehash these threads here. What has been said about the netbsd
> source repo applies equally to pkgsrc and pkgsrc-wip.
Bullshit. pkgsrc is fundamentally different from NetBSD in the nature of
data in the repository.
>> I strongly object to converting to git for following reasons:
>> 1. git doesn't support partial checkouts and other partial operations.
> "git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>…
> When <paths> or --patch are given, git checkout does not switch
> branches. It updates the named paths in the working tree from the
> index file or from a named <tree-ish> (most often a commit). "
> This is how you move part of the tree to a different commit. This has
> worked well for me in the past.
> Yes, there are no partial checkouts unless you do some gymnastics. But
> there are shallow clones, where you don't get the entire history. The
> full pkgsrc tree (not wip) with history is 1.5G, hardly a lot of space
> for modern hard drives.
Partial pkgsrc repository can easily be in range of 100M with full history.
>> 3. Merge abilities of git are total mess. Worse than CVS. (Yes, I've heard
>> all those lies many times. I cannot count merging head.1 with pom.6 as
>> "better merge support.")
> False. Once you learn how to merge, it is much better than what CVS
> offers. There was an excellent article recently that made the rounds
> (and that, unfortunately, I have not bookmarked) explaining basic git
> concepts in terms of what the underlying code actually does. There is
> fairly little magic involved.
Demonstrate it. So far I have heard this bullshit from about twenty different
self-proclaimed git experts and not a single person has demonstrated
successful recipe. Even if magical one. Original developer has failed to
merge changes between FreeBSD releases properly. (IIRC, the problem is
even worse: he didn't even notice failure.) Nobody else has yet demonstrated
how one procedes with merge when default way merges head.1 with pom.6
and large number of other totally unrelated files.
>> 1 and 2 apply to other similar version control systems. Changeset-only VCS
>> is very horrible fit for pkgsrc and pkgsrc-wip.
> This in itself is open for discussion. I disagree here -- again,
> having done actual work with pkgsrc on git.
I have done actual merge in git repository by importing large trees into CVS,
performing the actual merge in CVS and exporting changes back. (Yes, I could
probably use some other VCS that isn't total failure in merging like git is,
doing it with few commands in CVS was a matter of internal argument.)
>> Yes, and I don't see how this prevents Joyent from passing changes to
>> pkgsrc-wip right now. Pull requests are not commits, so they have to act
>> as a gateway anyway. It is the same as me accepting changes in personal
>> mail or pastebin service. Yes, some people do use mail and pastebin service
>> to contribute to wip.
> Again: How is that a reason for pkgsrc-wip, as a project, not to
> accept pull requests?
Nobody stops you from accepting changes in any other way that is convenient to you.
Yet this is not a reason to present your personal views as some sort of public consensus.
Main Index |
Thread Index |