[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request: Keyword $Rev$ with a twist

From: Julian Fitzell <julian_at_beta4.com>
Date: 2002-08-01 16:48:08 CEST

Josef Wolf wrote:
> On Thu, Aug 01, 2002 at 01:36:47AM -0700, Julian Fitzell wrote:
>>Josef Wolf wrote:
>>>There is no technical reason for the current behavior of cvs/svn, it
>>>is a _political_ decision.
>>>Maybe you could try again and give me a _real_ use case for mixed-revs?
>>>Please do not mis-understand me: I _know_ there are real use cases for
>>>mixed-revs. But I don't believe that those use-cases are so frequent
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>that it is worth to burden the day-by-day use.
>>I dunno, I sometimes have stable tagged versions of software checked out
> ^^^^^^^^^
>>and then want to update just one file that I know has had some important
>>bug fix made to it. Am I misunderstanding or doesn't that need mixed-revs?
> This is definitely a use case. But how often do you really do this?
> And what if this particular file has not only this particular bugfix
> but also some other changes? Why not _merge_ the bugfix onto the tagged
> version? You would need to merge anyway, when there are a lot of
> unrelated changes before the bugfix. What do you do with the WC after
> having this mixed state? Do you really go ahead and start to
> commit/merge/whatever? Or is this mixed state only temporary
> and you delete it after you are done with it?

I usually end up updating to the next tagged revision eventually.
Sometimes I might be making local changes as well, some times not.

I dunno, I can't I do it a *lot* but it's nice to be able to do and I
would miss it coming from CVS.


Beta4 Productions (http://www.beta4.com)
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 16:48:55 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.