Unique signature of a remote repository URLs or names.

[karajan1001]

Please provide information about your setup
DVC version(i.e. dvc --version), Platform and method of installation (pip, homebrew, pkg Mac, exe (Windows), DEB(Linux), RPM(Linux))

DVC version: 0.93
Platform: DEB
installation: pip

According to the discussion on #3470.
we should prevent duplicated remote repository names defining in different config levels.

$> dvc remote add --global sshrepo "ssh://user@test.com:/test1/"
$> dvc remote add sshrepo "ssh://user@test.com:/test2/" 　# this command should fail

[efiop]

@karajan1001 Hm, not sure why. Use case: in .dvc/config you have myremote and in .dvc/config.local you set your own password/credpath.

[karajan1001]

@karajan1001 Hm, not sure why. Use case: in .dvc/config you have myremote and in .dvc/config.local you set your own password/credpath.

@efiop I didn't consider this before. Maybe remote repo with the same names should use the same URLs?I think the question is what is the unique signature of the remote repository URLs or names.

For example, if we have two remote repo on different levels with the same name and different URLs. Both of them are set the default in their own levels. Currently, when we deleted the repo on the lower level, the default setting in the upper level will be deleted. We identify the remote repo by their names, but now remote with the same name may half different URLs. When should we consider two remote data the same? With the same name, with the same URLs, or only both? This affects the in what condition should we change the remote setting (removing default settings and renaming ) on different levels.

[efiop]

@karajan1001 Sorry for the delay.

You have very valid points, but I don't quite understand which use-case or scenario we are talking about. What issue are we trying to solve or what feature are we trying to implement? Or are we just revisiting the remote logic? 🙂

[karajan1001]

@efiop It's OK. I can't reply in time too.
This case.

And there was some discussion by @pared in #3470.

[efiop]

@karajan1001 Got it. Yes, dvc remote remove is trying to remove default remote from all levels.

The reason that logic was introduced was to avoid having a situation when a non-existing remote is still set as a default remote. So following that logic, in your example dvc remote remove should've either not touch the core.remote at all (because there is one at the top level) or also removed a remote with this name from the higher levels as well (as well as core.remotes). Need to give it a good thought.

[karajan1001]

@efiop Sorry for late, I am a little busy this week.

Yes, I think it's OK to remove all of the default remote repos, too. This is a safety strategy that causes no crucial damage. Someone who wants to push or pull files to or from a default remote will only receive an error.

But, in another case, for example in #3599 where we renamed the remote repos, we are in a totally different situation. If we renamed the remote repos along with the default remote. Someone may push or pull files to or from wrong remote repos without noticing that the default remote had been changed. In these cases maybe we shouldn't rename the default, or maybe we should throw out a warning, or maybe we should make the users decide whether the default be renamed.

I was looking into several config issues and found it hard to choose a universal strategy in the cases that there are two different repos with the same name. So I opened this issue to see if there were some standards solution to follow.

Maybe there was no universal solution, and we had to solve all these case by case. If so, I think it is OK to close this issue.