Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sourcehut welcomes Bitbucket refugees

sourcehut.org

Post reply on HN
Print view View original

181–190 of 219 posts

Re: Sourcehut welcomes Bitbucket refugees

#181

Post by elygre »

todd3834 wrote: post #161

I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.

Java OpenJDK development has been on Mercurial, and ponders moving to Git. In typical OpenJDK-fashion, the process is thoroughly examined and discussed. More information in for example

* https://openjdk.java.net/jeps/357

* https://github.com/openjdk/skara

* http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019....

Re: Sourcehut welcomes Bitbucket refugees

#182

Post by [deleted] »

panpanna wrote: post #49
viach wrote: post #47

Earlier quoted context omitted.

Are you going to say there is not even a distributed no-SQL cluster behind this? Well, I can understand the UI part, but there are limits...

Local config for static stuff and postgres yes-SQL. I assume it doesn't scale extremely easily but seems to work good enough for now.

[deleted]

Re: Sourcehut welcomes Bitbucket refugees

#184

Post by inspector-g »

kyrra wrote: post #93
ulkesh wrote: post #74

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

Technically I think Mercurial would be better for engineering wise in the long term. Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation. Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a s…

> Mercurial has better hooks in place

We use the hell out of this at my company. Mercurial's hooks have made a wide variety of automatic tasks much easier to systematize across all our repos for any repo-related action that any dev makes.

Here's one of our use cases. Mercurial, at least in the early days, had much better support (IMHO) for large/binary files than git (perhaps git is on-par now, not sure). We needed some of the projects in our repos to be fully compilable against any binaries/assets at any point in time in the repo's complete history. We implemented this with a combination of Mercurial's first-party "largefiles" extension, high compression of our binaries/assets (via 7z), and a variety of scripts/hooks to (de)compress the relevant files whenever `hg commit`, `hg up`, `hg revert`, etc. is performed.

Sure, you greatly increase the size of a repo on whatever machines are serving it, but storage is cheap these days so who cares. Devs also have to deal with more disk space being used, but a) storage is cheap and b) it is trivial to clear old binaries/assets from their disk on an automated schedule. Whenever they update/revert to another revision/branch the binaries/assets download automatically anyway.

Re: Sourcehut welcomes Bitbucket refugees

#185

Post by krupan »

BeetleB wrote: post #119
wilsonnb3 wrote: post #92

Earlier quoted context omitted.

Mercurial shouldn't be considered a pre-git source control system. It's initial release date was actually 12 days after git and it is far more comparable to git than it is to SVN and other pre-git version control systems.

I think he meant "the source control they used before using git" - not that it came out first.

But there really are people that purposefully went from git to hg. Calling hg a "pre-git" version control system makes some assumptions that just aren't true.

Re: Sourcehut welcomes Bitbucket refugees

#186

Post by ken »

Waterluvian wrote: post #120
viach wrote: post #41

They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS? There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.

To be fair, not having any of those technologies is just a side effect of deciding to make a dead simple, spartan UI (which isn't a bad thing). You can get away with very fast, very maintainable front-end code that doesn't need any special frameworks when you say no to modern tastes and features. More websites should really consider doing so. One of the things that breaks my heart just a little is visiting these site…

> To be fair, not having any of those technologies is just a side effect of deciding to make a dead simple, spartan UI (which isn't a bad thing).

That's also why google.com was originally so simple, in stark contrast to their competitors of the day.

Re: Sourcehut welcomes Bitbucket refugees

#187

Post by juped »

panpanna wrote: post #46
viach wrote: post #41

They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS? There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.

Monthly operational costs: $783 Maybe there is a relation?

Are you calling this high or low, and are you snarking or praising?

We're in way too deep here.

Re: Sourcehut welcomes Bitbucket refugees

#188

Post by rhizome »

notus wrote: post #141
majewsky wrote: post #116

Earlier quoted context omitted.

> for our company Is that in a single location? If so, then it's not really impressive. A good website loads fast even when the client is on the other side of the globe.

It goes out to all the cloudfront edge locations so that generally isn't an issue. That being said anything under 300ms is not going to be very noticeable to most people.

Contemporary fancysites might pull up a skeleton in that time, but it'll (often) take multiple seconds for every div to be populated and third-party request to return, juggling the page the whole time.

"Initial request to clickability" is definitely longer than it used to be.

Re: Sourcehut welcomes Bitbucket refugees

#189

Post by Drdrdrq »

jason_s wrote: post #171
steve_adams_86 wrote: post #164

Earlier quoted context omitted.

In my limited experience with Hg, I thought it had a well designed, human-friendly interface. After a decade with git, I still feel like it's an ugly, awkward tool that just gets the job done and I still occasionally make weird mistakes with it. I'm not sure that's the case with other tools I've been using this long. Git has a pretty gross interface, such that people have struggled to make it nicer to use with GUIs f…

...and because Atlassian let Bitbucket's Hg support wither and die.

I would say GitHub was the deciding factor. Atlassian at least supported hg, though BB never impressed me.

Re: Sourcehut welcomes Bitbucket refugees

#190

Post by fabrixxm »

Operyl wrote: post #136
ddevault wrote: post #42

Earlier quoted context omitted.

For more details on what the alpha entails, see also: https://sourcehut.org/alpha-details/

Is that page in a repo somewhere? There’s a typo or two to fix.

https://git.sr.ht/~sircmpwn/sourcehut.org/tree/master/conten...
Post reply on HN