Yes, but the commit would fail. Unfortunately, the editor doesn’t have a good
way to recover from that yet. The user would have to kill their edit session,
delete the local clone, and then restart the editor and redo their changes.
Ralph
> On Oct 16, 2018, at 8:01 AM, Matt Sicker wrote:
>
> A
Ah yeah, thanks for the context. So what if I ran a unique instance per
user? I suppose that could still end up in merge conflicts if two users try
to push a change concurrently.
On Mon, 15 Oct 2018 at 20:54, Ralph Goers
wrote:
> Yes, it would be non-trivial. The catalog editor uses jgit to acce
Yes, it would be non-trivial. The catalog editor uses jgit to access the
catalog. It has to clone it into a local repo and it loads it into an in-memory
database. Neither of these were designed to be access by multiple users at the
same time. For example, when you update the catalog it updates t
Is that nontrivial to support?
On Mon, 15 Oct 2018 at 16:48, Ralph Goers
wrote:
> The editor is not designed to be used by multiple users at the same time.
> Setting it up as a remote client will make people think you can do that.
>
> Ralph
>
> > On Oct 15, 2018, at 2:39 PM, Matt Sicker wrote:
The editor is not designed to be used by multiple users at the same time.
Setting it up as a remote client will make people think you can do that.
Ralph
> On Oct 15, 2018, at 2:39 PM, Matt Sicker wrote:
>
> Now I know the docs suggest running the catalog editor locally, but how
> well supporte
Now I know the docs suggest running the catalog editor locally, but how
well supported is it to run it remotely? Suppose I have a Kubernetes
cluster where my git credentials are available as a secret. Would it make
sense to run the catalog editor in the cluster (provided I've sufficiently
locked do
