Re: Revert or update to Issue 285: externals: prevent commit of pegged externals?

On 13.08.2013 21:18, Dan Ellis wrote:
>
> 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!

http://code.google.com/p/tortoisesvn/source/detail?r=24662

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3062581
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].