Sorry Ben - deleted the wrong addresses...
Frank Gruman wrote:
> I think one of the big fears from many of the threads I have read in
> here is exactly what you just stated about the repository remembering
> history.
>
> There is a fear that if a user collects to much garbage, they have no
> way of getting rid of it. So until the new features to obliterate
> files is introduced, people will continue to have a fear of adding
> what may end up becoming junk. So this concept of 'shelving' suddenly
> sounds neat and pretty because it allows me to make changes to my
> working copy and then make a record of it for others to see, feel, and
> play with without having to add any extra files to the repository.
> That in itself is working around the whole concept of controlling the
> code. Because now my patch can be added to/modified by someone else,
> but we just lost the original change to it. So it makes very little
> sense to keep a patch in an unversioned space.
>
> In Subversion, everyone needs to keep in mind that tags and branches
> are so very very cheap. You could have as many branches running at
> any time as you want, and each of them could be related to a brand new
> piece of functionality in the code. It's just a copy of the code
> sitting on a shelf (branch) waiting there for someone to look at it.
> If someone does touch it and play with it, when they put it back on
> the shelf (commit to that branch), it will have grown a little, but
> still not much. You could have 20 branches working, and unless
> someone is making massive changes to code in all of them, each will
> not cause undo growth in your repository. So you could browse your
> branches for works-in-progress (including the last minute, let's get
> this out for the big customer) to see what projects people are working
> on. That part is just a matter of doing a switch.
>
> my2c
>
> Regards,
> Frank
>
> Ben Collins-Sussman wrote:
>
>>
>> On Aug 2, 2005, at 4:46 PM, John wrote:
>>
>>>
>>> Do you think the repository is the best place for this? The text
>>> above implies
>>> intrinsically creating a branch (if I follow), so wouldn't it have
>>> to make
>>> assumptions about repos structure ('/branches' existing).
>>>
>>> My worry is that patches may be utter junk (!) and you don't want
>>> to keep an
>>> immutable copy of them, until approved (when they'd get committed).
>>
>>
>>
>> You have some notion that because the repository never loses data,
>> only "perfect" data should ever be written to it. That's overly
>> paranoid. People create long-lived feature branches all the time,
>> committing "broken" code for review. Eventually the feature branch
>> is finished and deleted.
>>
>> The main features of the repository is that it (1) remembers history
>> and (2) is a shared data resource; the history doesn't need to be
>> absolute perfection. If you become obsessed with making sure all
>> history is perfect, then you end up sacrificing feature #2 at times
>> when it would be really convenient! It's just not worth it.
>>
>> What's important is that your team follow policies that guarantee
>> stability in the *right places*: tags should be stable, trunk
>> should compile and pass tests, etc. But it's totally over-the-top
>> to insist that every byte in history be immaculate.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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 Wed Aug 3 00:28:51 2005