Opened 8 years ago

Closed 7 years ago

#2066 closed enhancement (fixed)

Fix new source steps' URL handling

Reported by: in3xes Owned by:
Priority: minor Milestone: 0.8.7
Version: 0.8.4p2 Keywords: simple
Cc: in3xes

Change History (9)

comment:1 Changed 7 years ago by dustin

  • Keywords Source removed

comment:2 Changed 7 years ago by dustin

  • Keywords simple added

See the referenced comments.

The new master-side source steps don't handle URLs the same way as the old (slave-side) source steps did, and this should be fixed.

comment:3 Changed 7 years ago by dustin

Copying the relevant parts from those comments:

baseURL vs svnurl

These names are confusing, and as I understand it, are just a vestige of backward compatibility. Since this step requires that users choose it explicitly, we have a chance to do it right. What do these two parameters accomplish, and how could we do that with one parameter, with lots of flexibility for the user? What about the common case when the repository in the SourceStamp? is sufficient - do we need to make the user specify a URL to the SVN step in that case, too? You don't need to implement the full flexibility yet, but think ahead when deciding how to handle these URLs.



This comment also applies to repoURL/baseURL of the Mercurial step. It would be good if all the new source steps could have consistent paramater naming among them selves, rather than with the old steps, which were not consistent.


Note that we've renamed svnurl to repourl (, but that wasn't the whole deal.

We've lost the advantage that I mentioned above - these steps are now in 0.8.5 and 0.8.6 production deployments using baseURL or repourl. Still, I'd be happy to see this simplified, even at the cost of some (well-documented, easily-mitigated) backward incompatibility.

comment:4 Changed 7 years ago by sa1

There is no simple way to handle subversion urls by just the baseURL, as there are no guarantees of patterns in how branches are stored in the svn file system.

For projects with no convention, repourl is the only way that is acceptable. e.g branches/dev/branch and branches/for-upstream may be the locations of two "branches". "branch" here simply means a folder that is buildable.

For projects that do have a convention as to how branches are stored, the documentation states that the baseURL and branch are simply concatenated together to derive the repoURL to use for the checkout. This is inadequate.

But the code contains a simpler way of specifying a convention for the branches by adding a branch_placeholder. If %%BRANCH%% is specified in the baseURL, it is replaced by branch in the generated repourl. This addresses a lot of simple branch conventions and is in my opinion the simplest way of adding flexibility for the user. This pattern of baseURL is also perhaps not compatible with the url in the source stamp. But I believe that this is the best way to handle the situation.

The configuration for specifying how branches are stored can be be made more complex for complicated setups if we want to have the required flexibility. To have an all-encompassing configuration does not seem to be possible. There is a sample BDF(branch description format) specified here which can be used to specify the location of branches but the scope of the description is too expansive for our purpose and only serves to indicate the complexity in such a task.

Other simple url patterns can be added later if they are in widespread use by some project.

comment:5 Changed 7 years ago by tom.prince

I wonder what if any behavior people expect when having a branch, when using repourl? It seems to me like it wouldn't be unreasonable to have the appending behavior apply to repourl, and have an option to specify the use of %%BRANCH%% as a placeholder in repourl. I don't actually use svn, so I don't know how well this would work.

comment:6 Changed 7 years ago by sa1

Yes, that should work. If there's no branch specified the extreme corner case(if its possible)that there's a folder named %%BRANCH%% is covered. :) If there's a branch specified and there's no placeholder in the repourl we can generate an error. I don't think people expect any behavior at the moment because the code would ignore the branch information completely. I also don't use svn much so feedback from actual users may be helpful.

Last edited 7 years ago by sa1 (previous) (diff)

comment:7 Changed 7 years ago by dustin

Comments are developing in the pull request -

comment:8 Changed 7 years ago by Saurabh Kumar

Remove baseURL in master-side SVN source step.

repourl takes over the functions of baseURL so that everything can be done with one url for the master-side SVN source step.

Branch considerations are removed from SVN master-side step. Branch info should be provided with Interpolate.

(refs #2066)

Changeset: 732c442afd234292c1fec8ac33f1a6a1d5a620dd

comment:9 Changed 7 years ago by dustin

  • Milestone changed from 0.8.+ to 0.8.7
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.