Hi Bob, that's definitely an issue.
However I think that are 2 issues by using this approach of considering only the remote db name and excluding the server/port component of the URL.
Imagine that on a CouchDB instance you trigger these 2 replications:
From what I understand, both will have the same replication ID with this patch, right?
If so you can't have both replications running in parallel, one of them will have conflict error when updating its checkpoint local doc (because it's the same for both).
Also, if you start replication 1, followed by replication 2 and then followed by replication 1 again, we can lose the benefits of the checkpointing.
Suppose you start replication 1, after it finishes the checkpoint document's most recent history entry has source sequence 1 000 000.
Then you start replication 2. Because the ID is the same as replication 1, it will overwrite the checkpoint document. If it checkpoints more than 50 times (the maximum history length), all checkpoint entries from replication 1 are gone. When it finishes, if you start replication 1 again, it will no longer find entries in the checkpoint history related to it, so the replication will start from sequence 0 instead of 1 000 000.
Basically, if we have a source or target like "http://user:email@example.com/dbname", I think we should consider everything from the URL except the password (eventually the protocol as well).