Backslash in Change Names?
15 views
Skip to first unread message
David E. Wheeler
Sep 10, 2022, 4:48:22 PM9/10/22
to Sqitch Users
Hello Sqitcheroos,
I have a pull request open that makes two changes to the allowed formatting of change and tag names:
https://github.com/sqitchers/sqitch/pull/681
* Disallow slashes in tag names. This is to fix https://github.com/sqitchers/sqitch/issues/680, and since the use of a slash breaks things on Ones that use a slash as a separator, I suspect it’s not a big deal.
* Disallow backslashes in change and tag names. I think they were allowed early on so that Windows users could use them for directory separators, but not long thereafter decided to that slashes in change names *always* act as directory separators, regardless of OS. But if anyone has been using backslashes in change names, it likely also resulted in directory separators, though only on Windows. This would bork cross-platform plans, but would probably work fine for Windows-only projects.
If you use Windows, can you tell me: do you ever use backslashes in your change names?
Also, would someone on Windows be willing to do a little experiment? I’d like to confirm the behavior of backslashes in change names. Could you create a plan like so:
sqitch init --engine sqlite
sqitch add first\change -n 'Add first’
sqitch deploy db:sqlite:test.db
And report back on what files were created in what directories and the output of the deploy? Also please send a copy of the plan.
If the deploy file is named “first\\change.sql” with literal backslashes, it means they are probably harmless and we don’t have to ban them.
If the file is instead named “change.sql” in the “deploy\first” directory, then it would not be cross-platform compatible, but might work okay on Windows (the deploy should confirm it). Then we would need to weigh whether or not to ban backslashes.
If it works okay on Windows, and we ban backslashes, anyone existing plans with backslashes in change names would not be able to deploy anymore. Changing the names for deployed plans would be onerous to say the least. Would need to carefully think through how to handle that.
Thanks,
David
I have a pull request open that makes two changes to the allowed formatting of change and tag names:
https://github.com/sqitchers/sqitch/pull/681
* Disallow slashes in tag names. This is to fix https://github.com/sqitchers/sqitch/issues/680, and since the use of a slash breaks things on Ones that use a slash as a separator, I suspect it’s not a big deal.
* Disallow backslashes in change and tag names. I think they were allowed early on so that Windows users could use them for directory separators, but not long thereafter decided to that slashes in change names *always* act as directory separators, regardless of OS. But if anyone has been using backslashes in change names, it likely also resulted in directory separators, though only on Windows. This would bork cross-platform plans, but would probably work fine for Windows-only projects.
If you use Windows, can you tell me: do you ever use backslashes in your change names?
Also, would someone on Windows be willing to do a little experiment? I’d like to confirm the behavior of backslashes in change names. Could you create a plan like so:
sqitch init --engine sqlite
sqitch add first\change -n 'Add first’
sqitch deploy db:sqlite:test.db
And report back on what files were created in what directories and the output of the deploy? Also please send a copy of the plan.
If the deploy file is named “first\\change.sql” with literal backslashes, it means they are probably harmless and we don’t have to ban them.
If the file is instead named “change.sql” in the “deploy\first” directory, then it would not be cross-platform compatible, but might work okay on Windows (the deploy should confirm it). Then we would need to weigh whether or not to ban backslashes.
If it works okay on Windows, and we ban backslashes, anyone existing plans with backslashes in change names would not be able to deploy anymore. Changing the names for deployed plans would be onerous to say the least. Would need to carefully think through how to handle that.
Thanks,
David
Reply all
Reply to author
Forward
0 new messages