Closed ChopperLee2011 closed 7 years ago
I suggest using your second recommendation, and we can create a lib
dir in repo's root, and provide methods like parseRepo
, repoNameEncoding
or repoNameDecoding
and we can share the method both front-end and back-end.
I had these comments in slack:
As @JuhaS mentioned, we could simply use the repo-id
; it won't break and will support renaming.
Actually I would probably recommend not tying the boards to the repositories directly at all. I mean we would have a board-id for each board that identifies them and maybe inside that define board-type and some github related fields. This would give us more flexibility in the future and decouple the board mechanics from anything github related. For example making it easier to create custom boards where board is tied to many repos, or personal boards where board is tied to user.
the backend uses Github repo name as one CouchDB database name, so follow CouchDB naming limitation
we can not create the cache DB which include '.'
so here is the solution base on the design for now:
a.b
andab
mean the same thing in our system. this will make customer confuse if he/she really have these two Github repos, but only can inbound one in our app..
symbol to legal symbol to CouchDB, like '$$' then,a.b
anda$$b
mean the same thing in our system, the good part is we can choose one symbol which we conside customer would not use in their Github repo, the bad part is we need to do parse in both backend and frontend.