You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Chris <sh...@yahoo.com> on 2006/08/10 20:42:55 UTC
Preventing bad commits
Some of our developers are unclear on the concept of version control,
and tend to upload a lot of junk in the system -- entire directories of
third-party code, for example, that they wanted to show other people.
How can I set things up so I can review developer commits, and back out
any mistakes?
What I need is some kind of workflow system, akin to the ones found in
content management systems, that allow a manager to review changes
before documents get posted to the next level.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Jeremy Pereira <je...@jeremyp.net>.
comments in line:
On 11 Aug 2006, at 17:13, Les Mikesell wrote:
> On Thu, 2006-08-10 at 19:43 -0400, Nico Kadel-Garcia wrote:
>
>>>> You could also require some review process before checkin.
>>>
>>> How? How can I see just the changes they'd like to make, and
>>> approve or
>>> disapprove of them?
>>
>> Take control of a "tags" or your "branches", by playing with
>> svnperms.py and
>> svnperms.conf. It easily allows one to set permissions to allow
>> the creation
>> of new tags, but their deletion only by a sitemaster, and changes
>> to trunk
>> only by the sitemaster. So force them to create a tag, then be
>> ready to
>> merge that tag when you're done.
>
> This doesn't really deal with the issue of getting cruft you don't
> want into the repository at all. If someone commits a bunch of
> huge files (or content that could incite a lawsuit for that matter)
> to a tag you can delete it so you don't see it in a HEAD view of
> the repository, but the content is still taking space in the
> repository and you can see it at the revision or time views when
> it was there.
I would tend to go for the "require a review process" idea. This
will have the advantage that it will educate your users about what
they should and shouldn't be checking in since that is the underlying
problem and anything else is just treating the symptoms..
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> ---------------------------------------------------------------------
> 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
Re: Preventing bad commits
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-08-10 at 19:43 -0400, Nico Kadel-Garcia wrote:
> >> You could also require some review process before checkin.
> >
> > How? How can I see just the changes they'd like to make, and approve or
> > disapprove of them?
>
> Take control of a "tags" or your "branches", by playing with svnperms.py and
> svnperms.conf. It easily allows one to set permissions to allow the creation
> of new tags, but their deletion only by a sitemaster, and changes to trunk
> only by the sitemaster. So force them to create a tag, then be ready to
> merge that tag when you're done.
This doesn't really deal with the issue of getting cruft you don't
want into the repository at all. If someone commits a bunch of
huge files (or content that could incite a lawsuit for that matter)
to a tag you can delete it so you don't see it in a HEAD view of
the repository, but the content is still taking space in the
repository and you can see it at the revision or time views when
it was there.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Chris" <sh...@yahoo.com>
To: <us...@subversion.tigris.org>
Sent: Thursday, August 10, 2006 7:09 PM
Subject: Re: Preventing bad commits
>> You could also require some review process before checkin.
>
> How? How can I see just the changes they'd like to make, and approve or
> disapprove of them?
Take control of a "tags" or your "branches", by playing with svnperms.py and
svnperms.conf. It easily allows one to set permissions to allow the creation
of new tags, but their deletion only by a sitemaster, and changes to trunk
only by the sitemaster. So force them to create a tag, then be ready to
merge that tag when you're done.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hi!
Jamie Wellnitz schrieb:
> True it's not perfect, but in a lot of environments the changes will
> be mostly text. That's the case with C source code, for instance.
Especially for C source files the svn:keywords property has also been
set.
> As I said, it depends heavily on what is in the repository.
> But, svn diff doesn't ignore all metadata:
OK, diff shows them but they can't be patched automatically by a
standard patch command.
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Jamie Wellnitz <Ja...@emulex.com>.
On Fri, Aug 11, 2006 at 04:05:01AM +0200, Andreas Schweigstill wrote:
> Dear Jamie!
>
> Jamie Wellnitz schrieb:
> >This probably depends heavily on what is in your repository. If it's
> >source code, or at least mostly plain text, you could have them send
> >out the output of "svn diff". This will generate a patch in unified
> >diff format, which you can look over or even apply locally.
>
> Unfortunately this doesn't handle changed on the meta-information
> correctly, like moves/renames, copies or attribute changes.
True it's not perfect, but in a lot of environments the changes will
be mostly text. That's the case with C source code, for instance. As
I said, it depends heavily on what is in the repository.
But, svn diff doesn't ignore all metadata:
% svn diff
Property changes on: aaa.c
___________________________________________________________________
Name: local:needs-work
+ lines 500-505
Property changes on: bbb.c
___________________________________________________________________
Name: svn:executable
+ *
>
> With best regards
> Andreas Schweigstill
Thanks,
Jamie
>
> --
> Dipl.-Phys. Andreas Schweigstill
> Schweigstill IT | Embedded Systems
> Schauenburgerstraße 116, D-24118 Kiel, Germany
> Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
> Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
>
> ---------------------------------------------------------------------
> 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
Re: Preventing bad commits
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Dear Jamie!
Jamie Wellnitz schrieb:
> This probably depends heavily on what is in your repository. If it's
> source code, or at least mostly plain text, you could have them send
> out the output of "svn diff". This will generate a patch in unified
> diff format, which you can look over or even apply locally.
Unfortunately this doesn't handle changed on the meta-information
correctly, like moves/renames, copies or attribute changes.
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Jamie Wellnitz <Ja...@emulex.com>.
On Thu, Aug 10, 2006 at 06:09:36PM -0500, Chris wrote:
> >You could also require some review process before checkin.
>
> How? How can I see just the changes they'd like to make, and approve or
> disapprove of them?
This probably depends heavily on what is in your repository. If it's
source code, or at least mostly plain text, you could have them send
out the output of "svn diff". This will generate a patch in unified
diff format, which you can look over or even apply locally.
This can be fairly easily scripted (on a Unix/Linux machine at least).
Jamie
>
> ---------------------------------------------------------------------
> 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
Re: Preventing bad commits
Posted by Chris <sh...@yahoo.com>.
> You could also require some review process before checkin.
How? How can I see just the changes they'd like to make, and approve or
disapprove of them?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Jamie Wellnitz <Ja...@emulex.com>.
On Thu, Aug 10, 2006 at 03:42:55PM -0500, Chris wrote:
> Some of our developers are unclear on the concept of version control,
> and tend to upload a lot of junk in the system -- entire directories of
> third-party code, for example, that they wanted to show other people.
>
> How can I set things up so I can review developer commits, and back out
> any mistakes?
>
> What I need is some kind of workflow system, akin to the ones found in
> content management systems, that allow a manager to review changes
> before documents get posted to the next level.
2 general methods:
You could have developers check into a staging branch, and then merge
changes from there to the production branch (or trunk).
You could also require some review process before checkin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Regards,
Jamie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Les Mikesell <le...@gmail.com>.
On Mon, 2006-08-28 at 09:39 -0400, Christopher Taylor wrote:
> well, at least this way the developers don't have access to trunk.
>
> Having said that, I'm assuming your talking about a commercial
> development effort ... sounds like you need either better training or
> better developers. If your developers can't understand something
> simple like version control, I'm afraid they probably won't produce
> decent software either.
Everybody has to start somewhere... And one of the good points of
using version control is that you can undo almost any mistake. Just
not the one of adding unwanted stuff, at least not without a massive
amount of administrator work.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Christopher Taylor <ch...@gmail.com>.
well, at least this way the developers don't have access to trunk.
Having said that, I'm assuming your talking about a commercial
development effort ... sounds like you need either better training or
better developers. If your developers can't understand something
simple like version control, I'm afraid they probably won't produce
decent software either.
-Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Bob Proulx <bo...@proulx.com>.
Christopher Taylor wrote:
> Stupid question time on this ... why can't you just assign each
> developer a branch to work on and then merge their branches back into
> the repository after it has been reviewed?
It is a good question. But the answer is that even in a branch what
the developer has checked in is still checked into the subversion
repository and is still stored in the back end. Using a branch will
not prevent license violations from occurring and will not prevent the
back end store from running out of disk space for everybody because a
(bad) developer committed things that they should not have committed.
The subversion repository still has everything in it. It is just less
visible.
To make an analogy, this would be like renaming files so that they are
"hidden files" and not shown in a typical directory listing. You
won't see them in typical use after that but the files will still be
there just the same.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Christopher Taylor <ch...@gmail.com>.
Stupid question time on this ... why can't you just assign each
developer a branch to work on and then merge their branches back into
the repository after it has been reviewed?
-Christopher
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Peter Werner <l....@vasas.no-ip.org>.
> > Some of our developers are unclear on the concept of version control,
> > and tend to upload a lot of junk in the system -- entire directories of
> > third-party code, for example, that they wanted to show other people.
>
> I feel your pain. I don't know why this is such a hard concept for
> many people to understand.
>
> > How can I set things up so I can review developer commits, and back out
> > any mistakes?
Perhaps two repositories? You "forward" good commits. This way you
will have a clean repository. The harder part is how to organize
cleaning out the developers' repo. You can overwrite it and they need
to do a new checkout. (Take care about changed revision numbers!)
WP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Preventing bad commits
Posted by Bob Proulx <bo...@proulx.com>.
Chris wrote:
> Some of our developers are unclear on the concept of version control,
> and tend to upload a lot of junk in the system -- entire directories of
> third-party code, for example, that they wanted to show other people.
I feel your pain. I don't know why this is such a hard concept for
many people to understand.
> How can I set things up so I can review developer commits, and back out
> any mistakes?
Using subversion in the model that all developers have commit access
this cannot be done. Because subversion tries really hard to preserve
data. Once committed it is committed. It is possible to svnadmin
dump, filter and load the repos but this is not done casually. There
is the "obliterate" command on the roadmap but I am not clear how the
workflow will work with it. This makes it very hard to undo commits
in subversion. Not something you can do as a casual part of the daily
work flow.
In FLOSS development it is rare for everyone to have commit access to
a project. Typically a maintainer or maintainer team are the only
ones allowed to commit changes. All others must submit their changes
as patches. These changes are reviewed and only committed after being
found acceptable. Often there is an interative process involved as
patches are rejected with requests for this or that improvement. The
submitter turns the patch and repeats until it is found acceptable.
Submitters are by this process mentored up the learning curve. Code
reviews pass on learning and knowledge. They learn what are good
practices and are bad. Usually people who have proved that they have
the skills and disposition are given direct commit access to the
repository.
This model works well. But this is very time consuming for the people
doing the patch review. They are by design a bottleneck to getting
changes put into the project. That is their job. To be the
gatekeeper. In concept this process is a centralized merge system
because they are the ones who end up merging changes.
However, implementing this type of a gatekeeper process in a corporate
business world may be unpalatable. It is often hard to explain to
management that while you are paying people these big salaries that
they are not trusted to commit changes without review. It may be true
but still unpalatable.
> What I need is some kind of workflow system, akin to the ones found in
> content management systems, that allow a manager to review changes
> before documents get posted to the next level.
I suggest that you look into a distributed version control system.
Let users commit to their local repository whatever trash they feel
like commiting. Then have your review board pull those changes into
the main repository.
Two systems come to mind. SVK works with subversion. I would
definitely take a look at it and gain some experience with it. It may
be well suited to your task. The other is git used by the linux
kernel development which was designed from the start to be a fully
distributed version control system. Both of these support a process
model where users have their own repository with full local commit
access then support pulling those changes into the main repository
after a review.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org