vcs icon indicating copy to clipboard operation
vcs copied to clipboard

Have svn return *something* from `Branches()` and `Tags()`

Open sdboyer opened this issue 9 years ago • 4 comments

Even though branches and tags in svn are just convention, it seems like it'd still be useful to enumerate those tags/branches that follow the basic convention.

As it stands, not having data reported back from there makes it nigh-impossible (in [vsolver][https://github.com/sdboyer/vsolver]-land, anyway) to have dependencies on such repos at all.

...ofc, we could also basically just ignore svn... :)

sdboyer avatar Mar 31 '16 13:03 sdboyer

@sdboyer This is something I've struggled with. I initially tried writing this package to optionally work with versions and branches for SVN. Since it's a convention and I've not had much call for it I opted out of the extra complexity. Pull requests are welcome.

mattfarina avatar Apr 05 '16 15:04 mattfarina

as i've other things that are more pressing in the area right now, i'm content to ignore it atm. deciding on something appropriate to svn's mechanics will take a level of thought that i just...yeah, need for other things

sdboyer avatar Apr 05 '16 17:04 sdboyer

Calling svn without an appropriate golang sdk is really frustrated.

markzhang0928 avatar Mar 19 '22 06:03 markzhang0928

In svn, tags and branches are folders like the trunk, which is the equivalent of master in Git. These folders do not always have the same location and name [1]. For example, the branch of a particular repository may be in a different location than the trunk folder.

From my point of view there are two solutions:

  1. (Maybe) better usability: make the tag/branch configurable (additional parameters in the NewSvnRepo() function).
  2. Easier to write: add the function SvnRepo.List() or Repo.List() which lists all files and folders in a remote path / svn repository (or DirList).

I can create a pull request, but before that I would like to hear your opinion.

simcrack avatar Nov 28 '22 19:11 simcrack