RE: What would be the best way to create "working repositories"?

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_at_gmail.com]
Sent: Tuesday, June 29, 2010 9:11 AM
To: Tom Malia
Cc: users_at_subversion.apache.org
Subject: Re: What would be the best way to create "working repositories"?

On 29 June 2010 13:54, Tom Malia <tommalia_at_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
Received on 2010-06-29 15:18:31 CEST