Editing External Code in a Working Copy

[Paul P.]

Hello,

Overall question: What is the best way to edit code referenced via externals?? I've tried a few ways, with varying success.

Details:

Apologies if this is a long post - trying to give as many details up-front to get the best responses possible.

The shared libraries are set up and working well in many cases for projects, where the shared libs are fairly stable.

Each of the components from the shared "library" are source-code components, needing to be included into a project in order to be run as intended. 

These components are generally considered "stable"... until features need to be added, bugs to be fixed... etc.

When new features are needed, or bugfixes need to be made, then comes the question, "How do I edit the external code?"

To edit one of these items, I've noticed a few possibilities:

1. Edit the item directly in a working copy

The file/folder created during the checkout and processing of the svn:externals property is, essentially, a nested checkout of the specified URL at the peg/explicit revision. 

Typically, we have externals going into discrete folders without any local items.

The workflow I have tried in this situation for editing HW interface code in a shared library:

- Update external WC

- Edit / Test / Commit

- TortoiseSVN prompts to update external's peg revision

--> Answer YES, or manually update external property

- Commit project WC

This approach works fairly well, but isn't immediately obvious to developers less experienced with Subversion/TortoiseSVN. 

One main drawback to this approach is when the external has its own branches/tags/trunk tree, and a branch/switch is needed to point the WC to appropriate folder.
TortoiseSVN does not appear to "pick up" the "switch" as well as it detects the revision # change mentioned above. ( if this is being addressed in a bugfix, I'd like to know... =) )

2. Editing the item referenced by external at its source

While this will always "work," it seems quite cumbersome, and difficult to get other (less-experienced) developers to follow.

Where the shared code needs to be included in another project to be tested on-target (especially for HW interfaces), I envision the workflow looking like:

- Edit the code in question in a project's WC (maybe even in the external directory)

- Test (hopefully!)

- Checkout the library item (branching if needed)

- Manually copy the changes from the project's WC to the library's WC, then commit

- Change project WC's svn:externals property, then update/test/commit

3. Remove external, copy item to project, modify, copy to library, recreate external

Not kidding... one developer actually went through the hassle of doing this...

Does anyone else run into this situation, and/or have a better way of managing it?

Thank you for your time and feedback!

Thanks,

Paul P.

[Stefan]

I would go with option 1. Unfortunately TSVN can not determine branches and offer to switch since it doesn't know the layout nor how you use the externals.

Of course, the proper way would be option 2: only this way can you ensure that all tests run properly on those libs, and you have control over when a new version should be released.
But that depends on your workflow.

[Paul P.]

Hi Stefan,

Thanks for your response. More or less, that is what I was expecting - just wasn't sure if there was a way I had missed.

Regarding TSVN not being able to determine "branches" and offer to switch: 

Perhaps I am missing some edge cases, but I would have expected it to be as "straightforward" as the current action with revisions. 

If a commit on the inner WC created by an external occurs, but that WC has switched to a different path, there is no value in offering to update the version. 

In fact, this can be potentially breaking, if the external URL has revs newer than the previous peg...

What I would (perhaps naievely) expect to occur, post commit (inner WC):

1. Check WC path vs. svn:external property path

--> If different, offer user to change

2. Check WC revision vs. svn:external property peg/operative revision

--> If different, offer user to change

I'd be curious to understand any use cases not considered or adequately addressed with this line of thought. I must be missing something... =)

I do appreciate the feedback you have provided, and can work with it. 

Thanks,

Paul P.

[Stefan]

On Wednesday, February 14, 2018 at 6:39:11 AM UTC+1, Paul P. wrote:

Hi Stefan,

Thanks for your response. More or less, that is what I was expecting - just wasn't sure if there was a way I had missed.

Regarding TSVN not being able to determine "branches" and offer to switch: 

Perhaps I am missing some edge cases, but I would have expected it to be as "straightforward" as the current action with revisions. 

If a commit on the inner WC created by an external occurs, but that WC has switched to a different path, there is no value in offering to update the version. 

In fact, this can be potentially breaking, if the external URL has revs newer than the previous peg...

What I would (perhaps naievely) expect to occur, post commit (inner WC):

1. Check WC path vs. svn:external property path

--> If different, offer user to change

Define "if different" :)
The external is definitely different, otherwise you wouldn't need an external.

And how would you determine the exact change to the external needed?

 

2. Check WC revision vs. svn:external property peg/operative revision

--> If different, offer user to change

This will always be different if the external comes from another repository.

Stefan