[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.

Daniel B.


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.