You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 4, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 4, 2025. It is now read-only.
It should be possible to show the different rows without a huge amount of development time, so expect that in (maybe) a month or so. eg not in the next few weeks
Development time is current being put into some foundation pieces for the online website instead, to enable visual diffs being done there. That bit is a lot of work, currently being done. 😉
As a thought, for a very manual workaround (for now), it should be possible to use the SQLite sqldiff command line tool: https://www.sqlite.org/sqldiff.html
When we implement the diff capability in dio, it'll likely be done (at least initially) by copying the approach there. 😄
At the moment, all commits are just stored as a brand new database. No optimisation whatsoever. 😉
That means - at present - there isn't a concept of conflicts, as each database is accepted verbatim (and stored as given).
The list of changes in Merge Requests (thus far) is very simple, just showing the commits that have occurred between the source and destination repo branches. It doesn't introspect the data at all to compare or diff between them.
That will improve over time, it's just turning out to be quite a lot of work needed to do this well:
Detect the difference(s)
Display them in meaning ways
For trivial differences - eg: just a few rows - neither of those is hard. For non-trivial things though, both can be very complicated. I'm still upgrading my skills for the display part, and haven't begun coding an initial prototype solution yet. 😦
It's all done on the commit level. If the merge request has a common point in shared commit history with the branch it's being merged to, it'll be allowed.
Things without a common/shared commit history make no sense, so Merge Requests aren't allowed on them.
It tries to follow the git model, and (thus far) seems pretty close.
If I send a merge request to merge fix into master, while there has been a new concurrent commit in master (C). There is a shared commit in history (B), however you say that there is no way to resolve conflicts. If this merge request is accepted, what happens?
A---B---C---M
\ /
D----
M is the same as D (losing commit C)? Or is this not allowed?
But how do you "append changes" to databases, if it has been modified in the target branch? You need a way to reconcile concurrent changes, and I'm asking if you have this or not.
At the moment, each commit is just the associated database for that commit. So, in the scenario above it'll just be the (complete) database from 'M'. The previous commits are still in the history, but there's no merging of data (etc) between the commits.
As a data point, the online visualisation capability we've been working on was recently made available. eg: example here
That's a pre-requisite for being able to generate and show diffs (and figure out how best to merge them), so we should be able to start working on that in the near future.
Hopefully it takes less than the ~year or so to get working, that the visualisation pieces did. 😉 There was lots of exploration-avenues-that-turned-out-to-be-useless for the visualisation stuff. 😦
If I send a merge request to merge fix into master, while there has been a new concurrent commit in master (C). There is a shared commit in history (B), however you say that there is no way to resolve conflicts. If this merge request is accepted, what happens?
A---B---C---M
\ /
D----
M is the same as D (losing commit C)? Or is this not allowed?
@remram44 We finally added support for merging in situations like you describe them. I you are still around I'd be very interested in your test results. On the website there are several "View Changes" buttons now which produce a diff. And it's possible to merge two branches now via a merge request.
For now we check if the same row of a table has been edited in both branches and if so abort with an error message. This is a bit too strict because we don't yet check if the changes are actually compatible. But as long as you don't have conflicts like this the MR is closed and the changes of C and D are part of M.
Activity
scottfurry commentedon May 12, 2019
Probably not the answer you were looking for, but from the README:
I don't use
go, so I'm unsure if this is the definitive answer.justinclift commentedon May 13, 2019
@urwork Yeah, we don't yet have the feature. 😦
It should be possible to show the different rows without a huge amount of development time, so expect that in (maybe) a month or so. eg not in the next few weeks
Development time is current being put into some foundation pieces for the online website instead, to enable visual diffs being done there. That bit is a lot of work, currently being done. 😉
justinclift commentedon May 13, 2019
As a thought, for a very manual workaround (for now), it should be possible to use the SQLite
sqldiffcommand line tool: https://www.sqlite.org/sqldiff.htmlWhen we implement the diff capability in dio, it'll likely be done (at least initially) by copying the approach there. 😄
remram44 commentedon Jul 26, 2019
I'm also wondering what kind of merges can dbhub handle? How are conflicts handled?
I was trying it for myself but ran into #6
justinclift commentedon Jul 26, 2019
At the moment, all commits are just stored as a brand new database. No optimisation whatsoever. 😉
That means - at present - there isn't a concept of conflicts, as each database is accepted verbatim (and stored as given).
The list of changes in Merge Requests (thus far) is very simple, just showing the commits that have occurred between the source and destination repo branches. It doesn't introspect the data at all to compare or diff between them.
That will improve over time, it's just turning out to be quite a lot of work needed to do this well:
For trivial differences - eg: just a few rows - neither of those is hard. For non-trivial things though, both can be very complicated. I'm still upgrading my skills for the display part, and haven't begun coding an initial prototype solution yet. 😦
remram44 commentedon Jul 26, 2019
How do branches and merge requests work, though? Do you only accept a merge if there are absolutely no concurrent changes?
justinclift commentedon Jul 26, 2019
It's all done on the commit level. If the merge request has a common point in shared commit history with the branch it's being merged to, it'll be allowed.
Things without a common/shared commit history make no sense, so Merge Requests aren't allowed on them.
It tries to follow the git model, and (thus far) seems pretty close.
remram44 commentedon Jul 26, 2019
But you say it can't resolve conflicts...
What happens in this case:
If I send a merge request to merge fix into master, while there has been a new concurrent commit in master (C). There is a shared commit in history (B), however you say that there is no way to resolve conflicts. If this merge request is accepted, what happens?
M is the same as D (losing commit C)? Or is this not allowed?
justinclift commentedon Jul 26, 2019
Well, after that merge the commit history should be A, B, C, M.
Hmmm, maybe create a 2nd account for yourself and try it out? 😄
Can create a test account for you if that'd be useful.
remram44 commentedon Jul 26, 2019
Unfortunately I ran into #6 and couldn't test further.
What is the result though? Are the changes from D lost? Are the changes from C lost?
justinclift commentedon Jul 26, 2019
None of the changes are lost. Like with git, it will pick the changes in the MR up and append them to the end of the target branch. 😄
I'll fix #6 over the next few days too. Sorry about that. 😦
remram44 commentedon Jul 26, 2019
But how do you "append changes" to databases, if it has been modified in the target branch? You need a way to reconcile concurrent changes, and I'm asking if you have this or not.
justinclift commentedon Jul 26, 2019
Ahhhh, now I get what you're asking.
At the moment, each commit is just the associated database for that commit. So, in the scenario above it'll just be the (complete) database from 'M'. The previous commits are still in the history, but there's no merging of data (etc) between the commits.
justinclift commentedon Jun 1, 2020
As a data point, the online visualisation capability we've been working on was recently made available. eg: example here
That's a pre-requisite for being able to generate and show diffs (and figure out how best to merge them), so we should be able to start working on that in the near future.
Hopefully it takes less than the ~year or so to get working, that the visualisation pieces did. 😉 There was lots of exploration-avenues-that-turned-out-to-be-useless for the visualisation stuff. 😦
MKleusberg commentedon Aug 31, 2020
@remram44 We finally added support for merging in situations like you describe them. I you are still around I'd be very interested in your test results. On the website there are several "View Changes" buttons now which produce a diff. And it's possible to merge two branches now via a merge request.
For now we check if the same row of a table has been edited in both branches and if so abort with an error message. This is a bit too strict because we don't yet check if the changes are actually compatible. But as long as you don't have conflicts like this the MR is closed and the changes of C and D are part of M.