> Hi all,
> Issue 285 was added to prevent a commit when an external had a
> pegged revision (only allowed for HEAD).
> I believe we should allow commits when the peg revision is the same
> as the HEAD revision. I'm ok with preventing commits to pegged
> revisions that are not the same as the HEAD. This makes some sense,
> although seems a little bit over-protective.
> Externals are used in our case to manage shared code between many
> projects. Requiring users to have a checkout of each of the shared
> code areas (of which there may be _many_) is unreasonable as is
> asking users to unpeg their revision prior to committing a change to
> the shared code base. We have some automated tools for managing
> externals that this is causing serious issues with.
> If we can't add an exception to allow commits to files, can we add a
> force command to allow a knowledgeable user to perform the action as
> We use some automated tools to help use manage the externals and
> this is throwing a pretty serious wrench into the gears. This also
> discourages our folks from contributing shared code as it means more
> work. Its hard enough to encourage sharing of code the way it is!
> Thanks in advance,
Has anyone put any consideration into this request for change? At this
point, this feature change breaks our process and is really a show stopper
for adoption of the 1.8.x line for us.
Thanks for your time,
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-13 17:08:34 CEST