You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrey Dibrov <ad...@softdev.spb.ru> on 2009/09/25 06:21:57 UTC
Fwd: Re[4]: public/private commits
Здравствуйте, users@subversion.tigris.org.
>>>> I uses SVN a long time, so i find out what SVN still doesn't have
>>>> someone feature. It will be very useful to organize into future
>>>> version of SVN new feature for commit action. Developers sometimes
>>>> wants to make commits for yourself to hide changes from other
>>>> developers in trunk or in branch. This is very useful if you want to commit
>>>> not complete or not enough tested changes to server, go home or other place
>>>> and take public update plus self private (not public) update to complete changes
>>>> and make later public commit.
>>>> Does this feature with public/private commit already exist?
>>
>>> Commit your "in progress" work to a branch you create, when complete
>>> merge your changes back to a common location (trunk or another
>>> branch).
>> This is really ambiguous to create branch per developer.
> How so? It keeps everyone's work isolated, which is what you're
> apparently looking for.
This is require administrative access to SVN to create a branch or
maintain it. A private/public commits shouldn't require them (may be
require, but only to active this kind of feature).
> The danger is that the longer you keep people isolated, the harder it
> will become to merge changes back together.
This is doesn't matter, developer can just don't commit a week or
more, what make commit harder too. Difference is in thing what
developer now can just store its own source changes on server
instead of local.
>>> Developers working together on a project should almost never have a
>>> need to hide things from each other. It's not good for the team.
>> Better doesn't see broken sources, than gonna get broken build. Team
>> shouldn't see private commit, it is useful only for developer who
>> made it.
> If each developer is committing to their own branch, who else will see
> the broken sources/build?
No one, this is ONLY for store changes, not for apply them.
--
С уважением,
Andrey mailto:adibrov@softdev.spb.ru
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2400093
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Fwd: Re[4]: public/private commits
Posted by Les Mikesell <le...@gmail.com>.
Andrey Dibrov wrote:
>>>> This is really ambiguous to create branch per developer.
>
>> How so? It keeps everyone's work isolated, which is what you're
>> apparently looking for.
> This is require administrative access to SVN to create a branch or
> maintain it.
No it doesn't, other than than making sure the developers have write access in
the path where you want their development branches.
> A private/public commits shouldn't require them (may be
> require, but only to active this kind of feature).
Branches are the usual/expected solution to this problem. Subversion doesn't
have any public/private concepts. Everything is just a path like any other to
subversion and you can do what you want in terms of content or access control
down any path. There are, of course, conventions for trunk/branches/tags, and
the convention for branches are what you are describing.
>> The danger is that the longer you keep people isolated, the harder it
>> will become to merge changes back together.
> This is doesn't matter, developer can just don't commit a week or
> more, what make commit harder too. Difference is in thing what
> developer now can just store its own source changes on server
> instead of local.
Yes, that's the point of branches - they isolate changes from other copies until
they are merged.
>>>> Developers working together on a project should almost never have a
>>>> need to hide things from each other. It's not good for the team.
>>> Better doesn't see broken sources, than gonna get broken build. Team
>>> shouldn't see private commit, it is useful only for developer who
>>> made it.
>
>> If each developer is committing to their own branch, who else will see
>> the broken sources/build?
> No one, this is ONLY for store changes, not for apply them.
An occasional broken build during development should not be considered a
disaster, especially when it is the result of different people making different
changes. It is often better to make them visible to everyone so they can agree
on the best solution which may very well not be in the code that you want to
keep isolated.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2401001
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Re[4]: public/private commits
Posted by Daniel Becroft <dj...@gmail.com>.
On Fri, Sep 25, 2009 at 4:21 PM, Andrey Dibrov <ad...@softdev.spb.ru>wrote:
> Здравствуйте, users@subversion.tigris.org.
>
> >>>> I uses SVN a long time, so i find out what SVN still doesn't have
> >>>> someone feature. It will be very useful to organize into future
> >>>> version of SVN new feature for commit action. Developers sometimes
> >>>> wants to make commits for yourself to hide changes from other
> >>>> developers in trunk or in branch. This is very useful if you want to
> commit
> >>>> not complete or not enough tested changes to server, go home or other
> place
> >>>> and take public update plus self private (not public) update to
> complete changes
> >>>> and make later public commit.
> >>>> Does this feature with public/private commit already exist?
> >>
> >>> Commit your "in progress" work to a branch you create, when complete
> >>> merge your changes back to a common location (trunk or another
> >>> branch).
> >> This is really ambiguous to create branch per developer.
>
> > How so? It keeps everyone's work isolated, which is what you're
> > apparently looking for.
> This is require administrative access to SVN to create a branch or
> maintain it. A private/public commits shouldn't require them (may be
> require, but only to active this kind of feature).
>
How does creating a branch require administrative access to SVN? It's just a
simple "svn cp" command.
The only thing I can think of is path-based authorisation, but that can be
easily worked around (free-for-all folder, branches-private, for example).
> > The danger is that the longer you keep people isolated, the harder it
> > will become to merge changes back together.
> This is doesn't matter, developer can just don't commit a week or
> more, what make commit harder too. Difference is in thing what
> developer now can just store its own source changes on server
> instead of local.
> >>> Developers working together on a project should almost never have a
> >>> need to hide things from each other. It's not good for the team.
> >> Better doesn't see broken sources, than gonna get broken build. Team
> >> shouldn't see private commit, it is useful only for developer who
> >> made it.
>
> > If each developer is committing to their own branch, who else will see
> > the broken sources/build?
> No one, this is ONLY for store changes, not for apply them.
>
If your changes are simple, generate and store patches. If not, private
branches are the generally accepted solution.
Cheers,
Daniel B.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2400991
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].