You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Charlie Davis <fi...@fishgills.net> on 2011/05/31 19:59:35 UTC
Using tags to manage releases?
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.
Is there a better way to do this? I feel like I'm missing something.
-Charlie
Re: Using tags to manage releases?
Posted by Ole Pinto <ol...@gmail.com>.
2011/6/1 Thorsten Schöning <ts...@am-soft.de>
> ...
> Therefore I would prefer proper proper merging by the developer,
> because you get a useful diff and log message in the changed file for
> QA.
>
At least, the merging could automatically be done on the server: when
getting the commit, take note of the revision being generated, and maybe
launch a task to do:
svn co ..../release/<rel_num> (unless it already exists, in which case, a
svn update would suffice)
svn merge --non-interactive .../trunk -c<revision previously generated>
Check for conflicts (maybe "svn st | grep "^ *C"); if there are, mail the
developer asking to merge manually.
If not, svn ci -m "Merged from trunk:<revision previously generated>:<log
from the trunk>"
Be careful to run those tasks in order...
Re: Using tags to manage releases?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Charlie Davis,
am Dienstag, 31. Mai 2011 um 19:59 schrieben Sie:
> 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.
If your script is triggered through keywords in a log message, why not
just omit those keywords in your automatically generated commit in the
script? They aren't useful anyway for QA, it's only a tool for your
developers to get they're commit into the release. Without those
keywords in your log message I don't see where the infinite loop could
happen. Just a svn copy without the delete would have triggered a
commit and a infinite loop, too. Everything creates a commit.
Besides that I don't think it's a good idea to delete and copy all the
way, because it makes debugging in case of an error harder than
necessary. If I change a file, commit it, delete another one and copy
the former changed file to the deleted, I don't get a diff of the real
changes but only the contents of the copied file. If QA finds an
error, you have to go to the log, look for the versions the copied one
differs in the former copied version and can't just work with a diff
of the changes to the file version QA got merged. What happens if a
developer made more than one commit to a file during his work and only
the last log message tells your script to copy the file. QA gets all
content because of the copy, but what does the log message tells QA
about the changes made?
Therefore I would prefer proper proper merging by the developer,
because you get a useful diff and log message in the changed file for
QA.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Using tags to manage releases?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 31, 2011, at 12:59, Charlie Davis wrote:
> 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.
>
> Is there a better way to do this? I feel like I'm missing something.
Yes, please reconsider your strategy. You really *do* want to release trunk (or, if you insist, a release branch) as a whole. You do *not* want to deploy individual files. How could you ever guarantee consistency? You can't. At the last web design company I worked for, before I introduced the team to Subversion, we would manually upload individual files to production by FTP. It was a nightmare of incompatibility. Subversion gives you tools to avoid that by helping you track your code changes and group them together meaningfully into folders, which you can then deploy in their entirety, knowing all the files in them work together.
Consider using trunk as the stable version of your web site. At any time, it should be acceptable to push trunk as a whole to production and it should work. If anybody is going to commit something that's going to break something for awhile, have them make a feature branch, work on things there until they're not broken, then merge it back to trunk.
Whenever you want to release the trunk, tag it. Then push the tag to production. There is a great script to help you with this, called SVN::Notify::Mirror. Look it up. Instead of keying off the log message as you proposed above, it keys off the tag name. (You get to define the pattern in the config file.) So anytime you want to publish your latest version, you simply "svn cp ..../trunk ..../tags/RELEASE-20110601" (or whatever your naming strategy is) and SVN::Notify::Mirror in the post-commit hook in the repository takes care of everything else. Ideally, your developers don't even have the passwords necessary to modify files on the production server, and all changes on the production server happen as a consequence of making a tag in the repository. This ensures all your code changes are tracked and reproducible.
Re: Using tags to manage releases?
Posted by Les Mikesell <le...@gmail.com>.
On 5/31/2011 1:43 PM, Charlie Davis wrote:
>
> 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?
If you want to isolate individual user's changes, have them make a
branch for their work and merge the changes when they are ready for qa.
--
Les Mikesell
lesmikesell@gmail.com
RE: Using tags to manage releases?
Posted by Bob Archer <Bo...@amsi.com>.
> On Tue, May 31, 2011 at 11:35 AM, Bob Archer <Bo...@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
> >
> 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.
I don't understand. You stated that the developer putting REL:15 in a log message was what trigged your script to copy it into the release branch. How is that any different than having the developer merge his commit into a release branch? It doesn't have to be the developer that does it... you can have some type of promotion process or something.
>
> 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?
Of course, everyone should not be working on their own version... but this seems contradictory.. you don't want everyone working in trunk but you don't want them each working on their own version. How can you have it both ways?
>
> 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).
But you just told me you DONT WANT the developers to decide when something gets moved to the QA release branch. Seriously Charlie you are confusing me.
Please don't top post!
BOb
Re: Using tags to manage releases?
Posted by Charlie Davis <fi...@fishgills.net>.
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 <Bo...@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
>
RE: Using tags to manage releases?
Posted by Bob Archer <Bo...@amsi.com>.
> 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