search

mtkennerly / dunamai

Dynamic versioning library and CLI
https://dunamai.readthedocs.io/en/latest
MIT License
321 stars 23 forks source link

Use repo root URL for Subversion tags path building, instead of the U… #10

Closed Spirotot closed 3 years ago

Spirotot commented 3 years ago

…RL for target.

mtkennerly commented 3 years ago

Thanks for your PR! I see that you didn't have to change anything in the tests. Could you explain how this behaves differently? If it fixes a potential problem, it would be great if you could add something to the tests to demonstrate the fix.

Also, it looks like some checks are failing, but they're definitely not related to your changes (something going wrong in the setup for older Git versions), so don't worry about that.

Spirotot commented 3 years ago

Hi @mtkennerly,

Sure, here is the behavior I noticed: When working from ^/trunk in a Subversion checkout, dunamai couldn't get the tags directory because svn info --show-item url returns the URL for the path you are currently working from, rather than the root of the SVN repository. So it was looking for tags in ^/trunk/tags. Passing --tag-dir "../tags" to dunamai (to make the tags path ^/trunk/../tags) also didn't work because the Subversion server I was working with doesn't allow .. in URLs.

This PR should get SVN to always return the actual root of the SVN repository, regardless of your current working directory within the repo. This also means that you should never have to pass .. as a value for --tag-dir since everything will be root-relative, instead of current-working-directory-relative.

In case you are not already familiar, the caret (^) is shorthand for "“the URL of the repository's root directory” (http://svnbook.red-bean.com/en/1.6/svn.basic.in-action.html). I believe an alternative to my change is to get rid of svn info --show item [url | repos-root-url] altogether and just use the caret instead.

I just took a look at the Subversion tests, and I think they didn't pick up this issue before since the working directory was never changed into a subdirectory, like /trunk. I think I've got the Subversion tests updated to cover the behavior I observed -- so the working directory is moved down into /trunk a couple times, now.

While I was working on the tests, I also noticed that svn info --show-item last-modified-revision would return what I believe to be the wrong commit number (and therefore the wrong version number) immediately post-tag when working in /trunk, so I swapped it out for svn info --show-item revision instead. I suppose the desired behavior here may actually be subjective, so please let me know if this was incorrect.

Let me know if this all makes sense! Thanks!

mtkennerly commented 3 years ago

That makes sense; thanks for the detailed explanation. The changes look great :+1: