I guess the problem I'm trying to circumvent is letting developers
just chug away on Trunk and marking files they believe ready for
release.
Having say, 4 people working on Trunk (day to day changes and what not
to the site), the another 4 working on separate site features (Who
would branch out to their own branches), how can cleanly deploy a set
of new files for the site while everyone is working on their own
version of the site?
Just having /trunk and /release might be enough (not necessarily
release 1, 2, 3, 4, 5, 6...) might work for a website. But having SVN
COPY not overwrite files is hampering this idea. This way QA can just
keep their testing copy up to date to the Release branch and
developers just put a tag into a commit message saying a file should
be moved to that Release branch without having to do a svn delete/svn
copy or creating an entirely new branch (This is a problem if someone
is just replacing a single word in a template).
On Tue, May 31, 2011 at 11:35 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> Hey everyone,
>> So here's what I'm trying to do and I'm wondering if I'm
>> approaching
>> this all wrong.
>>
>> First off, we are using Subversion for web site assets.
>>
>> Since its a website, its a very "organic" property. The method of
>> developing towards an end goal and then releasing that, doesn't
>> really
>> work for us. Meaning, everyone working in Trunk, getting Trunk to a
>> state we are happy, then tagging Trunk to a new branch and using
>> that
>> branch for release.
>>
>> What I'm doing is creating a post-commit script that, based upon
>> flags
>> in the commit message, does different actions.
>>
>> The idea being that someone could do say...
>>
>> svn commit -m "New awesome function. REL:15" scripts/support.js
>>
>> My little python script grabs the commit message, parses it out,
>> and
>> the idea is that Using the REL: "tag", it does:
>>
>> svn copy URL:/path/to/repo/trunk/scripts/support.js
>> URL:/path/to/repo/releases/15/scripts/support.js
>>
>> This way we deploy individual files to our QA, stage and production
>> environments. Our QA department could just keep their testing copy
>> at
>> the /releases/15 branch, our testing environment/production could
>> be
>> different releases and our developers can continue ahead working on
>> different areas of the site (Maybe developer A will need 2 months
>> to
>> do something, Developer B will take three days, etc...).
>>
>> Remember, we don't want to do big deploys of trunk as a whole, we
>> want
>> to be able to deploy parts of the site at a time.
>>
>> The problem I've come across is that SVN COPY doesn't work if the
>> file
>> exists... so... I made my script do a SVN delete, then a SVN COPY,
>> and
>> this creates a commit... and we get an infinite loop.
>
> This seems strange to me. If you have a release 15 how can you then release to that version again?
>
>
>> Is there a better way to do this? I feel like I'm missing
>> something.
>
> What I think you might want to consider is rather that your developer "tagging" the commit in the log message and automating moving it to your branch he should commit to trunk then merge that committed revision to your release/15 branch.
>
> Even more simple, if someone is working on release/15 why wouldn't they be committing changes directly to that branch? This seems like the more common use cases.
>
> Have you read the svn community guide on how they work there branching and release management? (though looks like there are some broken links there since http://subversion/docs/community-guide/releasing.html isn't working.)
>
>
> BOb
>
Received on 2011-05-31 20:44:12 CEST