21–30 of 30 posts
Earlier quoted context omitted.
That's because github isn't trying to be a replacement for JIRA and source control for most teams.
https://github.com/features/issues Scroll down to "break issues into actionable tasks", and they have an example that's even labeled as an "Epic". They are definitely headed in the same direction as Gitlab.
Earlier quoted context omitted.
For a full backup of a huge DB a three-hour window is pretty small, but I doubt that is what is happening here. A far more common setup is regular full backups, often daily though sometimes more/less frequent, with much smaller transaction log backups at high frequency, perhaps every 15 minutes, between. That way you lose at most what has happened since the last log backup, and you can restore to any point in time be…
Out of curiosity, how do transaction logs handle things like created_at fields, or randomly generated UUID, which rely on contextual data? Is the server time/rng seed faked for each replayed transaction?
I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
I didn't realize this wasn't common knowledge. It's been part of my everyday life for over ten years and several jobs. You can also add them to GitHub via ZenHub and other such tools.
Earlier quoted context omitted.
Huh. While trying to figure out the reasoning behind the name used, TIL that "epic" has acquired a new meaning of "(computing) In software development, a large or extended user story." https://en.wiktionary.org/wiki/epic
The name is an extension of '[user] story' - in literature, an epic is a collection of related stories (as in, The Epic of Gilgamesh), so they decided to call a collection of User Stories an Epic.
?
I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547
What is "(sic)" about "they are working to restore the data for the 313 items still affected"?
This is actually what they did, apparently: https://gitlab.com/gitlab-org/gitlab/-/issues/348547#note_77...
Earlier quoted context omitted.
The name is an extension of '[user] story' - in literature, an epic is a collection of related stories (as in, The Epic of Gilgamesh), so they decided to call a collection of User Stories an Epic.
Yes, that's what the definition I quoted said. ?
Earlier quoted context omitted.
For a full backup of a huge DB a three-hour window is pretty small, but I doubt that is what is happening here. A far more common setup is regular full backups, often daily though sometimes more/less frequent, with much smaller transaction log backups at high frequency, perhaps every 15 minutes, between. That way you lose at most what has happened since the last log backup, and you can restore to any point in time be…
Out of curiosity, how do transaction logs handle things like created_at fields, or randomly generated UUID, which rely on contextual data? Is the server time/rng seed faked for each replayed transaction?
[1] in fact it could just be logged at the page level, the granularity of the log structure will vary between systems, if logged at the row level it may be the case that the physical datafile after restore is not exactly the same but the data will still be “random” values & all.
I was hoping that this has something todo that i CANNOT delete my UnrealEngine repo/project in gitlab...but no, well it's not my storage ;)