Ok … So, no comment I will simply treat as lazy consensus, therefore I will move forward with tagging the main repo with the latest changes as last revision before the split and reference that in the commit to the new repo. Then I’ll simply copy over the files and delete them from the main repo.
As with other projects however, I really dislike this form of workting together. Defaulting back to lazy consensus costs a lot of valuable time as I have to wait a reasonable amount of time. If I had gotten any “sure … I’m fine with you doing X” I could have long finished this. In the future it would be a lot better, if some people would actually reply. Chris Von: Christofer Dutz <christofer.d...@c-ware.de> Datum: Donnerstag, 11. April 2024 um 10:36 An: dev@iotdb.apache.org <dev@iotdb.apache.org> Betreff: Splitting up the repos Hi all, so now that the new repo is created (https://gitbox.apache.org/repos/asf/iotdb-extras.git, but please don’t push anything there just yet), we would need to decide on which parts should be moved there. * “distribution”: Here I think we need to split the distribution. Keeping the distributions containing only core in the main repo and adding a new distribution module in the extras repo, that contains the downstream components. * “example” (which I would propose to rename to examples as it contains multiple) * “iotdb-connector” As it seems that in the integration-tests there are no tests testing the connectors, I guess we can leave that as it is. Now the problem is: There are multiple options to split up the repo and keeping the entire history. 1. Split out one directory in a separate branch and then merge all branches into an empty new one 2. Use the filter plugin to strip out all commits that match a regexp 3. Simply ignore the history, copy the files to the new repo and delete them from the old. 3 is the simples, but the person doing the move will be marked as author. In general this is not that problematic, as the integration modules and the examples are usually not that complex, but I would understand, if people wanted to keep the history. Option 1 is probably the most work, but the most robust option, as with option 2, I had to give up when doing the PLC4X split as there were bugs and issues in the tooling. So, if nobody objects and we’ve decided on what should be moved, I personally would opt for option 3. Chris
