You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tom Malia <to...@ttdsinc.com> on 2010/06/29 12:54:28 UTC
What would be the best way to create "working repositories"?
I'm looking for an easy way to allow programmers on a large project to
create something equivalent to a personal "branch" on the main project that
they can check their "Work In Process" (WIP) in and out of while they
actively develop a feature or enhancement over the period of several days to
several months. Then when they feel it's ready they need to do the
functionally equivalent to merging the branch back into trunk.
It appears that all this would be pretty simple if they literally did just
create a branch on the main project. However, for a number of different
reasons, I'd prefer that they could have a separate repository for their
WIP.
The scenario I'm thinking of is one in which there's a main company that
controls the project and tightly manages the Subversion Repo for it. They
are granting subcontractors rights to check-out parts of the project from
the main repository but they only want to allow those subcontractors to
"check in" product that is ready for at least Beta testing. In the mean
time, the subcontractors want to be able to check their WIP files in and out
of a repository over the course of the days or weeks that they are working
on it.
One thought I had, that I'd like to know if there's an easy way to do it or
if I'm just heading down the completely wrong path.
I'd like to be able to:
1) "export" sections of the "main" repository
2) Then add the directories that were just exported to a repository
that would the "working repo"
3) Check out the stuff just added to the "working repo" to a "working
copy" (WC)
4) Developer does their development in this WC, checking things into
the "working repo" whenever they wish to make sure the have a snapshot or
backup of their work
5) When the developer feels they are ready to "merge" their work back
in to the "main" repo they would do something like:
a. Check out the equivalent section of the "main" repo to a separate
WC
b. Delete everything from that WC
c. Copy everything from the "WC" that came from their "Working repo"
to the now "empty" WC from the main repo
d. Diff the current files in the "main" WC against the current version
of the "main" repo and resolve conflicts
e. Check the WC from the "main" repo back into main
f. Delete all WC folders from their local machine
g. Delete the entire "working repo"
One big flaw I see in this is, I'm not sure how deletes would be tracked,
though I'm sure there's plenty of other problems with this that I haven't
thought of. But then I'm guessing I'm not the first person to want to do
something like this.
A key aspect is, the end result HAS to be REALLY easy to teach people to do
and I need it in a Windows environment. Currently most of the developers
are not interested in knowing any more about Subversion than what they know
right now, which is, it acts "kind of like a network share".
Thanks in advance,
Tom Malia
T <http://www.ttdsinc.com> &T Data Solutions L.L.C.
RE: What would be the best way to create "working repositories"?
Posted by Tom Malia <to...@ttdsinc.com>.
We're good. Thanks.
Tom Malia
T <http://www.ttdsinc.com> &T Data Solutions L.L.C.
_____
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Tuesday, June 29, 2010 10:17 AM
To: Tom Malia
Cc: Andy Levy; users@subversion.apache.org
Subject: Re: What would be the best way to create "working repositories"?
On 29 June 2010 14:39, Tom Malia <to...@ttdsinc.com> wrote:
Completely understood and agreed.
As I said, I was setting the stage, not dictating the absolute.
I understood and agreed with Stephen's core points. I didn't find the
approach to communicating those points particular efficient.
Only one comment was tongue-in-cheek and it even had a smiley
All the rest were IMHO direct and too the point. Applogies if my brevity
causes offence
-Stephen
My goal with the "over taxed" developers is explicitly to reduce that load.
I am not necessarily "over taxed" and if necessary I'm looking for ways that
I can take on as much of the burden of learning and possibly doing the
processes necessary and only have to push as little as possible of that
burden to the developers.
Tom Malia
T&T Data Solutions L.L.C.
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Tuesday, June 29, 2010 9:24 AM
To: Tom Malia
Cc: Stephen Connolly; users@subversion.apache.org
Subject: Re: What would be the best way to create "working repositories"?
On Tue, Jun 29, 2010 at 09:16, Tom Malia <to...@ttdsinc.com> wrote:
> Stephen,
>
>
>
> I appreciate you taking the time to reply. I know many of your comments
are
> tongue-in-cheek and I don't take them too personally. However, I don't
find
> them terribly helpful either. I wont waste anymore bandwidth here on that
> aspect of your reply.
>
>
>
> I have no idea what GIT is. If it's another product that I would have to
> dedicate more resources to learning myself and training the already over
> taxed developers then I don't think it's a great idea for my situation.
A 5-second Google search will inform you as to what git is.
Stephen makes a valid point, though - if you & your developers are so
"overtaxed" that proper source control is too much to handle (this
includes your developers not understanding Subversion beyond what
you've described), then you have worse problems than the one you've
asked for help with here.
In the end, I think you'll find you spend more time, money & effort
doing it wrong than you will in training & staffing appropriately to
do it right. Or, to paraphrase a sign seen around my office: If don't
have time to do it right, when will you have time to do it twice?
Re: What would be the best way to create "working repositories"?
Posted by Stephen Connolly <st...@gmail.com>.
On 29 June 2010 14:39, Tom Malia <to...@ttdsinc.com> wrote:
> Completely understood and agreed.
>
> As I said, I was setting the stage, not dictating the absolute.
>
> I understood and agreed with Stephen's core points. I didn't find the
> approach to communicating those points particular efficient.
>
Only one comment was tongue-in-cheek and it even had a smiley
All the rest were IMHO direct and too the point. Applogies if my brevity
causes offence
-Stephen
> My goal with the "over taxed" developers is explicitly to reduce that load.
> I am not necessarily "over taxed" and if necessary I'm looking for ways
> that
> I can take on as much of the burden of learning and possibly doing the
> processes necessary and only have to push as little as possible of that
> burden to the developers.
>
> Tom Malia
> T&T Data Solutions L.L.C.
>
>
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Tuesday, June 29, 2010 9:24 AM
> To: Tom Malia
> Cc: Stephen Connolly; users@subversion.apache.org
> Subject: Re: What would be the best way to create "working repositories"?
>
> On Tue, Jun 29, 2010 at 09:16, Tom Malia <to...@ttdsinc.com> wrote:
> > Stephen,
> >
> >
> >
> > I appreciate you taking the time to reply. I know many of your comments
> are
> > tongue-in-cheek and I don’t take them too personally. However, I don’t
> find
> > them terribly helpful either. I wont waste anymore bandwidth here on
> that
> > aspect of your reply.
> >
> >
> >
> > I have no idea what GIT is. If it’s another product that I would have to
> > dedicate more resources to learning myself and training the already over
> > taxed developers then I don’t think it’s a great idea for my situation.
>
> A 5-second Google search will inform you as to what git is.
>
> Stephen makes a valid point, though - if you & your developers are so
> "overtaxed" that proper source control is too much to handle (this
> includes your developers not understanding Subversion beyond what
> you've described), then you have worse problems than the one you've
> asked for help with here.
>
> In the end, I think you'll find you spend more time, money & effort
> doing it wrong than you will in training & staffing appropriately to
> do it right. Or, to paraphrase a sign seen around my office: If don't
> have time to do it right, when will you have time to do it twice?
>
>
Re: What would be the best way to create "working repositories"?
Posted by Les Mikesell <le...@gmail.com>.
On 6/29/2010 8:39 AM, Tom Malia wrote:
> Completely understood and agreed.
>
> As I said, I was setting the stage, not dictating the absolute.
>
> I understood and agreed with Stephen's core points. I didn't find the
> approach to communicating those points particular efficient.
The first thing you need to consider is whether or not is is a good idea
to isolate your developers from each other. If you don't already have a
good spec with nailed down interfaces for components, you may just make
things worse when you try to merge the work done separately compared to
letting everyone update frequently to pick up others' changes on the
trunk and adapt as they go. Or if you do already have the interface
specs, maybe these separate components should be split into libraries
that could be completely isolated as different projects, perhaps even in
different repositories with the main program using external references
to pull them in. The latter approach might work if certain libraries
are permanently maintained by remote groups that want to have the
repository at their own locations. You could use svnsync to pull a
backup copy periodically if you want.
> My goal with the "over taxed" developers is explicitly to reduce that load.
> I am not necessarily "over taxed" and if necessary I'm looking for ways that
> I can take on as much of the burden of learning and possibly doing the
> processes necessary and only have to push as little as possible of that
> burden to the developers.
Subversion has a 'one central repository' model, so unless you can
completely split a project out to a different repository you would use
branches to isolate work. The git-svn suggestion permits something in
between where the remote developers would use git natively (probably no
harder than svn if you aren't already using one or the other) with the
git-svn program providing a link between their git work and the central
subversion repository so the changes could be pushed back only after the
work was complete. That is probably the closest you can get to your
initial request but as others have suggested, perhaps it really isn't
the best approach unless you have network connectivity issues that
interfere with using the central repository.
--
Les Mikesell
lesmikesell@gmail.com
RE: What would be the best way to create "working repositories"?
Posted by Tom Malia <to...@ttdsinc.com>.
Completely understood and agreed.
As I said, I was setting the stage, not dictating the absolute.
I understood and agreed with Stephen's core points. I didn't find the
approach to communicating those points particular efficient.
My goal with the "over taxed" developers is explicitly to reduce that load.
I am not necessarily "over taxed" and if necessary I'm looking for ways that
I can take on as much of the burden of learning and possibly doing the
processes necessary and only have to push as little as possible of that
burden to the developers.
Tom Malia
T&T Data Solutions L.L.C.
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Tuesday, June 29, 2010 9:24 AM
To: Tom Malia
Cc: Stephen Connolly; users@subversion.apache.org
Subject: Re: What would be the best way to create "working repositories"?
On Tue, Jun 29, 2010 at 09:16, Tom Malia <to...@ttdsinc.com> wrote:
> Stephen,
>
>
>
> I appreciate you taking the time to reply. I know many of your comments
are
> tongue-in-cheek and I dont take them too personally. However, I dont
find
> them terribly helpful either. I wont waste anymore bandwidth here on that
> aspect of your reply.
>
>
>
> I have no idea what GIT is. If its another product that I would have to
> dedicate more resources to learning myself and training the already over
> taxed developers then I dont think its a great idea for my situation.
A 5-second Google search will inform you as to what git is.
Stephen makes a valid point, though - if you & your developers are so
"overtaxed" that proper source control is too much to handle (this
includes your developers not understanding Subversion beyond what
you've described), then you have worse problems than the one you've
asked for help with here.
In the end, I think you'll find you spend more time, money & effort
doing it wrong than you will in training & staffing appropriately to
do it right. Or, to paraphrase a sign seen around my office: If don't
have time to do it right, when will you have time to do it twice?
Re: What would be the best way to create "working repositories"?
Posted by Andy Levy <an...@gmail.com>.
On Tue, Jun 29, 2010 at 09:16, Tom Malia <to...@ttdsinc.com> wrote:
> Stephen,
>
>
>
> I appreciate you taking the time to reply. I know many of your comments are
> tongue-in-cheek and I don’t take them too personally. However, I don’t find
> them terribly helpful either. I wont waste anymore bandwidth here on that
> aspect of your reply.
>
>
>
> I have no idea what GIT is. If it’s another product that I would have to
> dedicate more resources to learning myself and training the already over
> taxed developers then I don’t think it’s a great idea for my situation.
A 5-second Google search will inform you as to what git is.
Stephen makes a valid point, though - if you & your developers are so
"overtaxed" that proper source control is too much to handle (this
includes your developers not understanding Subversion beyond what
you've described), then you have worse problems than the one you've
asked for help with here.
In the end, I think you'll find you spend more time, money & effort
doing it wrong than you will in training & staffing appropriately to
do it right. Or, to paraphrase a sign seen around my office: If don't
have time to do it right, when will you have time to do it twice?
RE: What would be the best way to create "working repositories"?
Posted by Tom Malia <to...@ttdsinc.com>.
Stephen,
I appreciate you taking the time to reply. I know many of your comments are
tongue-in-cheek and I don't take them too personally. However, I don't find
them terribly helpful either. I wont waste anymore bandwidth here on that
aspect of your reply.
I have no idea what GIT is. If it's another product that I would have to
dedicate more resources to learning myself and training the already over
taxed developers then I don't think it's a great idea for my situation.
Tom Malia
T <http://www.ttdsinc.com> &T Data Solutions L.L.C.
_____
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Tuesday, June 29, 2010 9:11 AM
To: Tom Malia
Cc: users@subversion.apache.org
Subject: Re: What would be the best way to create "working repositories"?
On 29 June 2010 13:54, Tom Malia <to...@ttdsinc.com> wrote:
I'm looking for an easy way to allow programmers on a large project to
create something equivalent to a personal "branch" on the main project that
they can check their "Work In Process" (WIP) in and out of while they
actively develop a feature or enhancement over the period of several days to
several months. Then when they feel it's ready they need to do the
functionally equivalent to merging the branch back into trunk.
It appears that all this would be pretty simple if they literally did just
create a branch on the main project. However, for a number of different
reasons, I'd prefer that they could have a separate repository for their
WIP.
Would the number of reasons be:
1. You are a fool
;-)
The scenario I'm thinking of is one in which there's a main company that
controls the project and tightly manages the Subversion Repo for it. They
are granting subcontractors rights to check-out parts of the project from
the main repository but they only want to allow those subcontractors to
"check in" product that is ready for at least Beta testing. In the mean
time, the subcontractors want to be able to check their WIP files in and out
of a repository over the course of the days or weeks that they are working
on it.
Sounds like you would be better served with a distributed version control
system like GIT/Mercurial
Alternatively you could have the subcontractors work in GIT repos based off
the subversion repo. When ready you just pull an update from the GIT repo
and then committ the changes to SVN.
There are even tools to help automate the process.
One thought I had, that I'd like to know if there's an easy way to do it or
if I'm just heading down the completely wrong path.
I'd like to be able to:
1) "export" sections of the "main" repository
2) Then add the directories that were just exported to a repository
that would the "working repo"
3) Check out the stuff just added to the "working repo" to a "working
copy" (WC)
4) Developer does their development in this WC, checking things into
the "working repo" whenever they wish to make sure the have a snapshot or
backup of their work
5) When the developer feels they are ready to "merge" their work back
in to the "main" repo they would do something like:
a. Check out the equivalent section of the "main" repo to a separate
WC
b. Delete everything from that WC
c. Copy everything from the "WC" that came from their "Working repo"
to the now "empty" WC from the main repo
d. Diff the current files in the "main" WC against the current version
of the "main" repo and resolve conflicts
e. Check the WC from the "main" repo back into main
f. Delete all WC folders from their local machine
g. Delete the entire "working repo"
One big flaw I see in this is, I'm not sure how deletes would be tracked,
though I'm sure there's plenty of other problems with this that I haven't
thought of. But then I'm guessing I'm not the first person to want to do
something like this.
Loads of issues with resolving merge conflicts because you are throwing away
the change history, so there will effectively be no merge history
A key aspect is, the end result HAS to be REALLY easy to teach people to do
and I need it in a Windows environment. Currently most of the developers
are not interested in knowing any more about Subversion than what they know
right now, which is, it acts "kind of like a network share".
If you have developers who don't care about version control then you have
worse problems.
Thanks in advance,
Tom Malia
T <http://www.ttdsinc.com> &T Data Solutions L.L.C.
-Stephen
Re: What would be the best way to create "working repositories"?
Posted by Stephen Connolly <st...@gmail.com>.
On 29 June 2010 13:54, Tom Malia <to...@ttdsinc.com> wrote:
> I’m looking for an easy way to allow programmers on a large project to
> create something equivalent to a personal “branch” on the main project that
> they can check their “Work In Process” (WIP) in and out of while they
> actively develop a feature or enhancement over the period of several days to
> several months. Then when they feel it’s ready they need to do the
> functionally equivalent to merging the branch back into trunk.
>
>
>
> It appears that all this would be pretty simple if they literally did just
> create a branch on the main project. However, for a number of different
> reasons, I’d prefer that they could have a separate repository for their
> WIP.
>
> Would the number of reasons be:
1. You are a fool
;-)
>
>
> The scenario I’m thinking of is one in which there’s a main company that
> controls the project and tightly manages the Subversion Repo for it. They
> are granting subcontractors rights to check-out parts of the project from
> the main repository but they only want to allow those subcontractors to
> “check in” product that is ready for at least Beta testing. In the mean
> time, the subcontractors want to be able to check their WIP files in and out
> of a repository over the course of the days or weeks that they are working
> on it.
>
> Sounds like you would be better served with a distributed version control
system like GIT/Mercurial
Alternatively you could have the subcontractors work in GIT repos based off
the subversion repo. When ready you just pull an update from the GIT repo
and then committ the changes to SVN.
There are even tools to help automate the process.
>
>
> One thought I had, that I’d like to know if there’s an easy way to do it or
> if I’m just heading down the completely wrong path.
>
>
>
> I’d like to be able to:
>
> 1) “export” sections of the “main” repository
>
> 2) Then add the directories that were just exported to a repository
> that would the “working repo”
>
> 3) Check out the stuff just added to the “working repo” to a
> “working copy” (WC)
>
> 4) Developer does their development in this WC, checking things into
> the “working repo” whenever they wish to make sure the have a snapshot or
> backup of their work
>
> 5) When the developer feels they are ready to “merge” their work
> back in to the “main” repo they would do something like:
>
> a. Check out the equivalent section of the “main” repo to a separate
> WC
>
> b. Delete everything from that WC
>
> c. Copy everything from the “WC” that came from their “Working repo”
> to the now “empty” WC from the main repo
>
> d. Diff the current files in the “main” WC against the current
> version of the “main” repo and resolve conflicts
>
> e. Check the WC from the “main” repo back into main
>
> f. Delete all WC folders from their local machine
>
> g. Delete the entire “working repo”
>
>
>
> One big flaw I see in this is, I’m not sure how deletes would be tracked,
> though I’m sure there’s plenty of other problems with this that I haven’t
> thought of. But then I’m guessing I’m not the first person to want to do
> something like this.
>
Loads of issues with resolving merge conflicts because you are throwing away
the change history, so there will effectively be no merge history
>
>
> A key aspect is, the end result HAS to be REALLY easy to teach people to do
> and I need it in a Windows environment. Currently most of the developers
> are not interested in knowing any more about Subversion than what they know
> right now, which is, it acts “kind of like a network share”.
>
>
> If you have developers who don't care about version control then you have
worse problems.
> Thanks in advance,
>
> Tom Malia
>
> T&T Data Solutions L.L.C. <http://www.ttdsinc.com>
>
>
>
>
>
-Stephen
Re: What would be the best way to create "working repositories"?
Posted by Tino Schwarze <su...@tisc.de>.
Hi Tom,
On Tue, Jun 29, 2010 at 09:37:24AM -0400, Tom Malia wrote:
> I do understand that my people will have to get a little more sophisticated
> about Subversion than "it's just a file share" and I think you understand
> that my statement of the simplicity "requirement" is to say that, I have to
> keep how much deeper they need to go as limited as is practical and still be
> able to implement a solution.
>
> I believe I will be taking your advice about just use real "branches" in the
> "main" repo..
>
> I myself am no Subversion "expert". I don't do a lot of "merge" stuff.
> BTW, I and almost all the developers on this project use TortoiseSVN almost
> exclusively as their SVN interface.
>
> Can you perform "merge" functionality directly "at the repo" or do I need to
> check out working copies to perform these processes?
You always need a working copy. And if you're going to do the merging
(instead of the developers), you might want to have them ready to answer
questions if conflicts arise.
A good strategy for your setup might be:
1. assign developer A a particular feature to implement
2. create a branch for that feature and tell the developer to use this
to check in his/her work in progress (whether or not this is a "private"
branch is solely an organisational decision)
2a. (optional) the developer may merge-in changes to the main branch on
demand
3. if the work is done, do a --reintegrate merge into the trunk (or
the branch of the main product). After that, the feature branch is
considered dead (but may be revived).
4. create a new branch for the next feature (even for same developer),
so he/she will pick up the latest developments
HTH,
Tino.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Tuesday, June 29, 2010 9:17 AM
> To: Tom Malia
> Cc: users@subversion.apache.org
> Subject: Re: What would be the best way to create "working repositories"?
>
> On Tue, Jun 29, 2010 at 08:54, Tom Malia <to...@ttdsinc.com> wrote:
> > Im looking for an easy way to allow programmers on a large project to
> > create something equivalent to a personal branch on the main project
> that
> > they can check their Work In Process (WIP) in and out of while they
> > actively develop a feature or enhancement over the period of several days
> to
> > several months. Then when they feel its ready they need to do the
> > functionally equivalent to merging the branch back into trunk.
> >
> >
> >
> > It appears that all this would be pretty simple if they literally did just
> > create a branch on the main project. However, for a number of different
> > reasons, Id prefer that they could have a separate repository for their
> > WIP.
>
> Developer/feature branches really are the best way to go here,
> especially given your need to keep things simple and abstract the
> actual Subversion usage away from your users as much as possible.
>
> > The scenario Im thinking of is one in which theres a main company that
> > controls the project and tightly manages the Subversion Repo for it. They
> > are granting subcontractors rights to check-out parts of the project from
> > the main repository but they only want to allow those subcontractors to
> > check in product that is ready for at least Beta testing. In the mean
> > time, the subcontractors want to be able to check their WIP files in and
> out
> > of a repository over the course of the days or weeks that they are working
> > on it.
>
> Why not allow those subcontractors to commit to their private
> branches, then have someone central who is the "gatekeeper" and either
> merges from the branch to somewhere else, or accepts patches, at the
> beta stage?
>
> > One thought I had, that Id like to know if theres an easy way to do it
> or
> > if Im just heading down the completely wrong path.
> >
> > Id like to be able to:
> > 1) export sections of the main repository
> > 2) Then add the directories that were just exported to a repository
> > that would the working repo
> > 3) Check out the stuff just added to the working repo to a
> working
> > copy (WC)
> > 4) Developer does their development in this WC, checking things into
> > the working repo whenever they wish to make sure the have a snapshot or
> > backup of their work
> > 5) When the developer feels they are ready to merge their work
> back
> > in to the main repo they would do something like:
> > a. Check out the equivalent section of the main repo to a separate
> > WC
> > b. Delete everything from that WC
> > c. Copy everything from the WC that came from their Working repo
> > to the now empty WC from the main repo
> > d. Diff the current files in the main WC against the current
> version
> > of the main repo and resolve conflicts
> > e. Check the WC from the main repo back into main
> > f. Delete all WC folders from their local machine
> > g. Delete the entire working repo
> >
> > One big flaw I see in this is, Im not sure how deletes would be tracked,
> > though Im sure theres plenty of other problems with this that I havent
> > thought of. But then Im guessing Im not the first person to want to do
> > something like this.
>
> The other big flaw is that it prevents changes in the central
> repository from propagating down to your subcontractors. If you keep
> it all in one repository, you can merge changes from trunk (or other
> branches) to each developer's private branch. There's a lot of
> overhead here and a huge margin for error & possibly even loss of
> data. Portions of step 5 would be covered by svn_load_dirs.pl but
> overall I'm having trouble understanding how this solves your
> situation well while satisfying your below requirement.
>
> > A key aspect is, the end result HAS to be REALLY easy to teach people to
> do
> > and I need it in a Windows environment. Currently most of the developers
> > are not interested in knowing any more about Subversion than what they
> know
> > right now, which is, it acts kind of like a network share.
>
> I'm afraid this may break *any* solution proposed. At some point,
> people *do* have to understand the tools their using, especially if
> they're using them in a non-standard way.
>
> SVK or git-svn may be able to meet your technical requirements without
> too much trouble, but they'd probably break your "people"
> requirements.
--
"What we nourish flourishes." - "Was wir nähren erblüht."
www.tisc.de
Re: What would be the best way to create "working repositories"?
Posted by Tino Schwarze <su...@tisc.de>.
Hi Tom,
On Tue, Jun 29, 2010 at 09:37:24AM -0400, Tom Malia wrote:
> I do understand that my people will have to get a little more sophisticated
> about Subversion than "it's just a file share" and I think you understand
> that my statement of the simplicity "requirement" is to say that, I have to
> keep how much deeper they need to go as limited as is practical and still be
> able to implement a solution.
>
> I believe I will be taking your advice about just use real "branches" in the
> "main" repo..
>
> I myself am no Subversion "expert". I don't do a lot of "merge" stuff.
> BTW, I and almost all the developers on this project use TortoiseSVN almost
> exclusively as their SVN interface.
>
> Can you perform "merge" functionality directly "at the repo" or do I need to
> check out working copies to perform these processes?
You always need a working copy. And if you're going to do the merging
(instead of the developers), you might want to have them ready to answer
questions if conflicts arise.
A good strategy for your setup might be:
1. assign developer A a particular feature to implement
2. create a branch for that feature and tell the developer to use this
to check in his/her work in progress (whether or not this is a "private"
branch is solely an organisational decision)
2a. (optional) the developer may merge-in changes to the main branch on
demand
3. if the work is done, do a --reintegrate merge into the trunk (or
the branch of the main product). After that, the feature branch is
considered dead (but may be revived).
4. create a new branch for the next feature (even for same developer),
so he/she will pick up the latest developments
HTH,
Tino.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Tuesday, June 29, 2010 9:17 AM
> To: Tom Malia
> Cc: users@subversion.apache.org
> Subject: Re: What would be the best way to create "working repositories"?
>
> On Tue, Jun 29, 2010 at 08:54, Tom Malia <to...@ttdsinc.com> wrote:
> > Im looking for an easy way to allow programmers on a large project to
> > create something equivalent to a personal branch on the main project
> that
> > they can check their Work In Process (WIP) in and out of while they
> > actively develop a feature or enhancement over the period of several days
> to
> > several months. Then when they feel its ready they need to do the
> > functionally equivalent to merging the branch back into trunk.
> >
> >
> >
> > It appears that all this would be pretty simple if they literally did just
> > create a branch on the main project. However, for a number of different
> > reasons, Id prefer that they could have a separate repository for their
> > WIP.
>
> Developer/feature branches really are the best way to go here,
> especially given your need to keep things simple and abstract the
> actual Subversion usage away from your users as much as possible.
>
> > The scenario Im thinking of is one in which theres a main company that
> > controls the project and tightly manages the Subversion Repo for it. They
> > are granting subcontractors rights to check-out parts of the project from
> > the main repository but they only want to allow those subcontractors to
> > check in product that is ready for at least Beta testing. In the mean
> > time, the subcontractors want to be able to check their WIP files in and
> out
> > of a repository over the course of the days or weeks that they are working
> > on it.
>
> Why not allow those subcontractors to commit to their private
> branches, then have someone central who is the "gatekeeper" and either
> merges from the branch to somewhere else, or accepts patches, at the
> beta stage?
>
> > One thought I had, that Id like to know if theres an easy way to do it
> or
> > if Im just heading down the completely wrong path.
> >
> > Id like to be able to:
> > 1) export sections of the main repository
> > 2) Then add the directories that were just exported to a repository
> > that would the working repo
> > 3) Check out the stuff just added to the working repo to a
> working
> > copy (WC)
> > 4) Developer does their development in this WC, checking things into
> > the working repo whenever they wish to make sure the have a snapshot or
> > backup of their work
> > 5) When the developer feels they are ready to merge their work
> back
> > in to the main repo they would do something like:
> > a. Check out the equivalent section of the main repo to a separate
> > WC
> > b. Delete everything from that WC
> > c. Copy everything from the WC that came from their Working repo
> > to the now empty WC from the main repo
> > d. Diff the current files in the main WC against the current
> version
> > of the main repo and resolve conflicts
> > e. Check the WC from the main repo back into main
> > f. Delete all WC folders from their local machine
> > g. Delete the entire working repo
> >
> > One big flaw I see in this is, Im not sure how deletes would be tracked,
> > though Im sure theres plenty of other problems with this that I havent
> > thought of. But then Im guessing Im not the first person to want to do
> > something like this.
>
> The other big flaw is that it prevents changes in the central
> repository from propagating down to your subcontractors. If you keep
> it all in one repository, you can merge changes from trunk (or other
> branches) to each developer's private branch. There's a lot of
> overhead here and a huge margin for error & possibly even loss of
> data. Portions of step 5 would be covered by svn_load_dirs.pl but
> overall I'm having trouble understanding how this solves your
> situation well while satisfying your below requirement.
>
> > A key aspect is, the end result HAS to be REALLY easy to teach people to
> do
> > and I need it in a Windows environment. Currently most of the developers
> > are not interested in knowing any more about Subversion than what they
> know
> > right now, which is, it acts kind of like a network share.
>
> I'm afraid this may break *any* solution proposed. At some point,
> people *do* have to understand the tools their using, especially if
> they're using them in a non-standard way.
>
> SVK or git-svn may be able to meet your technical requirements without
> too much trouble, but they'd probably break your "people"
> requirements.
--
"What we nourish flourishes." - "Was wir nähren erblüht."
www.tisc.de
RE: What would be the best way to create "working repositories"?
Posted by Tom Malia <to...@ttdsinc.com>.
Thanks Andy. This is an extremely useful reply.
I do understand that my people will have to get a little more sophisticated
about Subversion than "it's just a file share" and I think you understand
that my statement of the simplicity "requirement" is to say that, I have to
keep how much deeper they need to go as limited as is practical and still be
able to implement a solution.
I believe I will be taking your advice about just use real "branches" in the
"main" repo..
I myself am no Subversion "expert". I don't do a lot of "merge" stuff.
BTW, I and almost all the developers on this project use TortoiseSVN almost
exclusively as their SVN interface.
Can you perform "merge" functionality directly "at the repo" or do I need to
check out working copies to perform these processes?
Tom Malia
T&T Data Solutions L.L.C.
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Tuesday, June 29, 2010 9:17 AM
To: Tom Malia
Cc: users@subversion.apache.org
Subject: Re: What would be the best way to create "working repositories"?
On Tue, Jun 29, 2010 at 08:54, Tom Malia <to...@ttdsinc.com> wrote:
> Im looking for an easy way to allow programmers on a large project to
> create something equivalent to a personal branch on the main project
that
> they can check their Work In Process (WIP) in and out of while they
> actively develop a feature or enhancement over the period of several days
to
> several months. Then when they feel its ready they need to do the
> functionally equivalent to merging the branch back into trunk.
>
>
>
> It appears that all this would be pretty simple if they literally did just
> create a branch on the main project. However, for a number of different
> reasons, Id prefer that they could have a separate repository for their
> WIP.
Developer/feature branches really are the best way to go here,
especially given your need to keep things simple and abstract the
actual Subversion usage away from your users as much as possible.
> The scenario Im thinking of is one in which theres a main company that
> controls the project and tightly manages the Subversion Repo for it. They
> are granting subcontractors rights to check-out parts of the project from
> the main repository but they only want to allow those subcontractors to
> check in product that is ready for at least Beta testing. In the mean
> time, the subcontractors want to be able to check their WIP files in and
out
> of a repository over the course of the days or weeks that they are working
> on it.
Why not allow those subcontractors to commit to their private
branches, then have someone central who is the "gatekeeper" and either
merges from the branch to somewhere else, or accepts patches, at the
beta stage?
> One thought I had, that Id like to know if theres an easy way to do it
or
> if Im just heading down the completely wrong path.
>
> Id like to be able to:
> 1) export sections of the main repository
> 2) Then add the directories that were just exported to a repository
> that would the working repo
> 3) Check out the stuff just added to the working repo to a
working
> copy (WC)
> 4) Developer does their development in this WC, checking things into
> the working repo whenever they wish to make sure the have a snapshot or
> backup of their work
> 5) When the developer feels they are ready to merge their work
back
> in to the main repo they would do something like:
> a. Check out the equivalent section of the main repo to a separate
> WC
> b. Delete everything from that WC
> c. Copy everything from the WC that came from their Working repo
> to the now empty WC from the main repo
> d. Diff the current files in the main WC against the current
version
> of the main repo and resolve conflicts
> e. Check the WC from the main repo back into main
> f. Delete all WC folders from their local machine
> g. Delete the entire working repo
>
> One big flaw I see in this is, Im not sure how deletes would be tracked,
> though Im sure theres plenty of other problems with this that I havent
> thought of. But then Im guessing Im not the first person to want to do
> something like this.
The other big flaw is that it prevents changes in the central
repository from propagating down to your subcontractors. If you keep
it all in one repository, you can merge changes from trunk (or other
branches) to each developer's private branch. There's a lot of
overhead here and a huge margin for error & possibly even loss of
data. Portions of step 5 would be covered by svn_load_dirs.pl but
overall I'm having trouble understanding how this solves your
situation well while satisfying your below requirement.
> A key aspect is, the end result HAS to be REALLY easy to teach people to
do
> and I need it in a Windows environment. Currently most of the developers
> are not interested in knowing any more about Subversion than what they
know
> right now, which is, it acts kind of like a network share.
I'm afraid this may break *any* solution proposed. At some point,
people *do* have to understand the tools their using, especially if
they're using them in a non-standard way.
SVK or git-svn may be able to meet your technical requirements without
too much trouble, but they'd probably break your "people"
requirements.
Re: What would be the best way to create "working repositories"?
Posted by Andy Levy <an...@gmail.com>.
On Tue, Jun 29, 2010 at 08:54, Tom Malia <to...@ttdsinc.com> wrote:
> I’m looking for an easy way to allow programmers on a large project to
> create something equivalent to a personal “branch” on the main project that
> they can check their “Work In Process” (WIP) in and out of while they
> actively develop a feature or enhancement over the period of several days to
> several months. Then when they feel it’s ready they need to do the
> functionally equivalent to merging the branch back into trunk.
>
>
>
> It appears that all this would be pretty simple if they literally did just
> create a branch on the main project. However, for a number of different
> reasons, I’d prefer that they could have a separate repository for their
> WIP.
Developer/feature branches really are the best way to go here,
especially given your need to keep things simple and abstract the
actual Subversion usage away from your users as much as possible.
> The scenario I’m thinking of is one in which there’s a main company that
> controls the project and tightly manages the Subversion Repo for it. They
> are granting subcontractors rights to check-out parts of the project from
> the main repository but they only want to allow those subcontractors to
> “check in” product that is ready for at least Beta testing. In the mean
> time, the subcontractors want to be able to check their WIP files in and out
> of a repository over the course of the days or weeks that they are working
> on it.
Why not allow those subcontractors to commit to their private
branches, then have someone central who is the "gatekeeper" and either
merges from the branch to somewhere else, or accepts patches, at the
beta stage?
> One thought I had, that I’d like to know if there’s an easy way to do it or
> if I’m just heading down the completely wrong path.
>
> I’d like to be able to:
> 1) “export” sections of the “main” repository
> 2) Then add the directories that were just exported to a repository
> that would the “working repo”
> 3) Check out the stuff just added to the “working repo” to a “working
> copy” (WC)
> 4) Developer does their development in this WC, checking things into
> the “working repo” whenever they wish to make sure the have a snapshot or
> backup of their work
> 5) When the developer feels they are ready to “merge” their work back
> in to the “main” repo they would do something like:
> a. Check out the equivalent section of the “main” repo to a separate
> WC
> b. Delete everything from that WC
> c. Copy everything from the “WC” that came from their “Working repo”
> to the now “empty” WC from the main repo
> d. Diff the current files in the “main” WC against the current version
> of the “main” repo and resolve conflicts
> e. Check the WC from the “main” repo back into main
> f. Delete all WC folders from their local machine
> g. Delete the entire “working repo”
>
> One big flaw I see in this is, I’m not sure how deletes would be tracked,
> though I’m sure there’s plenty of other problems with this that I haven’t
> thought of. But then I’m guessing I’m not the first person to want to do
> something like this.
The other big flaw is that it prevents changes in the central
repository from propagating down to your subcontractors. If you keep
it all in one repository, you can merge changes from trunk (or other
branches) to each developer's private branch. There's a lot of
overhead here and a huge margin for error & possibly even loss of
data. Portions of step 5 would be covered by svn_load_dirs.pl but
overall I'm having trouble understanding how this solves your
situation well while satisfying your below requirement.
> A key aspect is, the end result HAS to be REALLY easy to teach people to do
> and I need it in a Windows environment. Currently most of the developers
> are not interested in knowing any more about Subversion than what they know
> right now, which is, it acts “kind of like a network share”.
I'm afraid this may break *any* solution proposed. At some point,
people *do* have to understand the tools their using, especially if
they're using them in a non-standard way.
SVK or git-svn may be able to meet your technical requirements without
too much trouble, but they'd probably break your "people"
requirements.