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

Re: Re[4]: public/private commits

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Mon, 28 Sep 2009 09:27:54 +1000

On Fri, Sep 25, 2009 at 4:21 PM, Andrey Dibrov <adibrov_at_softdev.spb.ru>wrote:

> Здравствуйте, users_at_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_at_subversion.tigris.org].
Received on 2009-09-28 01:29:09 CEST

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.