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

Re: Shelving

From: Duncan Murdoch <subversion_at_murdoch-sutherland.com>
Date: 2005-12-05 15:18:13 CET

On 12/5/2005 8:13 AM, Flanakin Michael C Ctr HQ OSSG/OMR wrote:
> The main reason I like shelving is because I've been in numerous
> situations where code changes need to be passed from one person to the
> next or, due to project needs, you're required to stop working one task
> to start another. Personally, I'd like to have a place to save these
> changes without committing them. This is of course based on my VC
> methodology - only commit completed, compilable code (say that 5xs
> fast). Of course, the files could be saved locally, but then they risk
> being accidentally deleted. I'd rather have all these changes in one
> place, rather than risking rework. This way, any developer can pick up
> where another left off, if need be.
>
> I also don't completely agree with your opinion that it's a backup. I do
> see what you mean, but it depends on how the shelves are used. For
> instance, a team may have the C4 philosophy I use, but a developer may
> want to commit their changes more frequently for a large code change.
> Shelves can directly support that.
>
> Whether you call them shelves or private branches, I could care less.
> It's the capability that I think would be important to document.

I think the idea of private branches is used in a lot of the branching
examples in the book, but isn't explicitly described in the section
"Common Branching Patterns" (only implicitly as "Feature Branches").
Why not submit a patch to that section, and mention the word "shelving"?
  It might not be accepted, but at least the authors will get your point
clearly.

Duncan Murdoch

>
> Michael
>
>
> -----Original Message-----
> From: allan juul [mailto:allan@muly.dk]
> Sent: Saturday, December 03, 2005 6:38 AM
> To: Flanakin Michael C Ctr HQ OSSG/OMR
> Cc: users@subversion.tigris.org
> Subject: Re: Shelving
>
> Flanakin Michael C Ctr HQ OSSG/OMR wrote:
>> I think it'd be best to have a separate root directory to distinguish
>> the concept separately. In effect, I may want to shelve 3 files,
>> whereas I would branch the entire repository. Or, would shelving the
>> entire repository be the recommended practice, in this instance?
>>
>>>From what I remember, shelving (or private branching) isn't discussed
>>>in
>> the docs. Would it be beneficial to officially accept a "shelves"
>> directory as a best practice and update the docs? I think it'd be nice
>
>> to publicly announce the feature so those who are new to Svn (and even
>
>> CM as a whole) can understand how it's done as well as understand the
>> differences between branches and shelves. In my opinion, saying that
>> shelves are branches is like saying that tags are branches (or
>> vice-versa). Technically, they are; however, conceptually they are
>> completely different. Again, just my opinion.
>>
>> Michael
>
> i personally think "shelving" is perhaps the most overrated "feature" in
> modern version control systems. i wouldn't even consider it a
> "nice-to-have". AFAIU a "shelve" isn't even version controlled - it's
> just a backup on the same server that happens to be your version control
> system as well. therefore IMO a "shelve" is just a private unversioned
> branch.
>
> but if you really want a "shelving" "feature" i think that i agree in
> you should name your root dir "shelves" or something like that.
>
> ./alan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 15:22:16 2005

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

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