Stefan Küng <tortoisesvn_at_gmail.com> wrote on 08/13/2013 11:20:43 AM:
> From: Stefan Küng <tortoisesvn_at_gmail.com>
> To: users_at_tortoisesvn.tigris.org
> Date: 08/13/2013 11:21 AM
> Subject: Re: Revert or update to Issue 285: externals: prevent
> commit of pegged externals?
>
> On 13.08.2013 17:08, Dan Ellis wrote:
> > Hello everyone,
> >
> > > 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.
>
> if you peg to HEAD, then why even add a peg revision?
> If you peg to a specific revision, then it won't be HEAD anymore when
> you do the commit.
> The only way to determine whether it's the same as HEAD would be to do a
> diff with the repository.
>
> Now imagine TSVN would have to do such a diff in the commit dialog.
>
> --> 100s time required just to figure out whether the externals are the
> same as HEAD.
>
> --> users would be waiting outside my apartment for me to get out so
> they can kill me.
OK,I totally buy that as a reason with the stipulation that you are
already harassing the server a bunch with the commits - the overhead of
grabbing HEAD is probably quite a bit less than the actually commits of
the same files. We do a server svn info on each changed file (XML
info/entry/commit) to fetch the latest the server has and compare to what
our WC has. I assume this is what you meant by "diff" and not actually
doing a diff. That would stink.
So some context to our approach might make my thoughts more clear. In
managing a product line, we have a metric ton of shared source code. This
common code doesn't fit well into a "library" model either (e.g. take all
the SIN/COS functions and toss them in mymath.lib). At a high-level, each
project's source code is by default shared with any project that baselines
from it. If you have project A that came first and did great stuff,
project A+ could comes along and baseline from A but only change a couple
files. Branching just doesn't fit the bill on this. From that point on,
all the files that have not been "forked" are truly shared (via
externals). Project A+ will still see updates from A and can decide if
they like the changes, or want to "fork" if they don't like the changes.
We don't want to force users to have to perform an evaluation at each
update (it might be a year before A+ does its next version 1.1) If we had
every project point to HEAD for these shared bits, then they would
automatically get changes pulled into their build (not very CM-like).
This form of product line management is becoming more and more popular as
it does not require a product-reuse committee - each project makes their
own decisions and their code is by default shared with everyone else as
well. This approach is very similar to Rational's CMVC (use of a
"history" in addition to a filename and revision). Over time, projects
can see a large number of different histories of files from all sorts of
places they didn't expect. This sure beats clone and own and it beats
forcing creation and management of libraries. A ton of the shared code
would never really fit into a library format anyway.
Talking more specific, in our case, all our files for all projects belong
to a single area in the repo separated by a "history" tag (implemented as
a folder). History name is likely the project that created it, but could
also be variations of a history (dual LAN, Host/Target) - essentially
anything descriptive. Pegs prevent a program from injected unwanted
change to another project that might be using the same file.
In essence, all files that a developer works with are externals and we
want to keep externals as invisible to the developer as possible (not all
developers are, can be or want to be CM experts).
Collectively, we might disagree on the approach, but we can do that for
basically any CM approach, right? So I'm hoping with some context, that I
can demonstrate a valid case for wanting to perform this action.
Having to unpeg an external to commit a change makes the product line
approach burdensome and frankly its hard to get folks to reuse source code
already. This worked in TSVN 1.7 and SVN 1.8 still allows this. In my
opinion, TSVN 1.8 is making an (unfair) assumption about how users wish to
implement CM. There are valid cases for wishing to commit an external
that is pegged.
So what about making the option to prohibit committing of pegged revisions
a feature that can be turned on/off via the Settings option? This allows
behavior consistent with previous versions but also provides a safety net
for those not wanting that feature?
I hope this clarifies a bit more. let me know!
Thanks,
Dan
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3062569
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-13 21:18:22 CEST