Transfer mode set to Awesome http://transfermodeawesome.posterous.com Dorkly bits on Exchange, Windows, software and whatever else I can think of. posterous.com Mon, 19 Apr 2010 20:22:00 -0700 Patching Redmine 0.8.x for email notifications on added news items regardless of user notification settings http://transfermodeawesome.posterous.com/2010/04/patching-redmine-08x-for-email.html http://transfermodeawesome.posterous.com/2010/04/patching-redmine-08x-for-email.html

That’s a mouthful.

Redmine 0.8.x does not send email notifications about added news items unless the user’s notification settings are set to permit updates about everything in the project, including all issue updates, etc.  This isn’t a very happy medium.

There is a ticket, #2549 at redmine.org that describes a “watch” feature for the news feed.  This would be ideal.  Since no real action seems to have been taken on it in the last year, I found a way to patch (read: hack) a dumb notification feature into the code.  I provide no warranty for this, it’s provided AS-IS.

The idea is that instead of sending to a project recipient list that has been filtered for users not wishing to see all notifications, to instead simply send to all project members.  To do this, I added a new method to the projects class which provides this unfiltered email list.  It requires two patches:

=== (+2,-2) apps/redmine/app/models/mailer.rb ===
@@ -101,7 +101,7 @@
   def news_added(news)
     redmine_headers 'Project' => news.project.identifier
-    recipients news.project.recipients
+    recipients news.project.news_recipients
     subject "[#{news.project.name}] #{l(:label_news)}: #{news.title}"
     body :news => news,
          :news_url => url_for(:controller => 'news', :action => 'show', :id => news)

and:

=== (+5,-1) apps/redmine/app/models/project.rb ===
@@ -205,6 +205,10 @@
     members.select {|m| m.mail_notification? || m.user.mail_notification?}.collect {|m| m.user.mail}
   end
+  def news_recipients
+    members.collect {|m| m.user.mail}
+  end

   # Returns an array of all custom fields enabled for project issues
   # (explictly associated custom fields and custom fields enabled for all projects)
   def all_issue_custom_fields

 

The second change create a new method, “news_recipients”, which is simply the email list of group members.  The first change makes the news_added event use the news_recipients list instead of the project’s regular recipients list.

This is a very naive approach, isn’t sanctioned by anyone, including me, and could easily have problems I don’t understand.  For example, I have no idea what this does with project members who have been locked out in the administration interface.  If security and privacy are important to your organization, do not use this patch.  You've been warned.

On a side note, I use Mercurial’s MQ extension to maintain such patches to source code on a production system.  This allows me to run with the patches until upgrade time, then to lift and reapply the patches after the upgrade process completes.

Permalink | Leave a comment  »

]]>
Sat, 27 Feb 2010 05:08:00 -0800 Useful links for understanding Mercurial and Git http://transfermodeawesome.posterous.com/2010/02/useful-links-for-understanding.html http://transfermodeawesome.posterous.com/2010/02/useful-links-for-understanding.html

The basics

Comparisons

While the link below isn’t really a comparison so much as a set of suggestions for git, it happens to highlight some of the things I think Mercurial does right:

http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less

Unfortunately, almost all of the rest of the comparisons that show up on Google at the time of this writing are significantly out of date.  There are some good comparisons which enumerate what used to be valid reasons for choosing one system over the other, however, times are changing rapidly for these systems.  The following, while a bit out of date, are still relevant comparisons that have good highlights of the systems:

I list the Python PEP primarily because it contains some good workflow discussions.  The first two are a bit more up-to-date.

The one that reflects my own reasons for choosing Mercurial best is this:

http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/

I believe git repositories automatically optimize periodically now, so that’s less of a difference.  Mercurial now has hgsubversion to work with Subversion repositories as well.  Mercurial supports not only named branches within a repository but also git-style bookmarks, which differs from the article here too.

Finally, a pretty up-to-date and under-the-hood technical comparison of how they work is at Stack Overflow:

http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast

Permalink | Leave a comment  »

]]>
Sat, 20 Feb 2010 19:59:00 -0800 Git and Mercurial…mostly Mercurial http://transfermodeawesome.posterous.com/2010/02/git-and-mercurialmostly-mercurial.html http://transfermodeawesome.posterous.com/2010/02/git-and-mercurialmostly-mercurial.html

This is not so much a comparison of Git and Mercurial as a recounting of my experience looking at the two. If you are looking to make a decision between them, I can tell you two important things:

  1. All of my research indicates that when it comes to the technical capabilities of the two systems, they are so similar as to be almost indistinguishable. They both do the job and in almost exactly the same fashion. One will have a slight advantage over the other in any number of ways, but when it boils down, you won’t find anything compelling about one’s capabilities over the other.  And they are growing more similar over time as each implements the ideas of the other (at least, this is definitely the case with Mercurial borrowing features such as rebasing from git).
  2. That said, the environment in which you are operating makes a huge difference. The punchline is that, if you want to deploy a repository server and you run a windows-focused environment, then you have no choice but Mercurial (at the time of this writing).

In this article, I’ll cover:

  • Background and motivation for looking at distributed version control systems

In further articles I’ll cover:

  • Useful links for understanding and comparing the systems
  • Evaluating the capabilities of the systems
  • Working with Git on Windows
  • Experience with Mercurial

I’ll be writing a short series with more detail on my deeper experiences with Mercurial as well.

Motivation

The biggest motivation for looking at the so-called “next generation” of version control systems, the distributed version control systems or DVCSs, is that of the merge.

At my place of employment we currently use Subversion for version control purposes.  It’s a great system and one we’ve used for a long time, and I’ve personally used it even longer.  However, it works best when you don’t do a lot of branching.  Branches are treated as second-class citizens, a special case to be given special consideration only when actually attempting to merge results from the branch back into the trunk.  At that point, our experiences have indicated two things (even with the new merge tools introduced with Subversion 1.5):

  1. Merges rarely go off without a hitch.
  2. Merges make you go through a battery of options which require a thorough knowledge of the merge process.

The upshot of this is that it discourages use of branching.  Our head developer wants to worry about coding rather than the details of version control, and I don’t blame him.  A good rule for Subversion is to never let your branches drift far from your trunk, which requires frequent merging of trunk changes into your branches.  Because merges frequently encounter conflicts in Subversion (some new types of conflict were introduced with 1.5 as well which I still don’t understand and aren’t well documented), it’s just less of a headache to work on the trunk and leave branches out of the picture except for major feature-development.  Even then, it’s a pain.

Of course, working on just the trunk has its own issues, which version control should be suited to fixing, but can’t handle well without branching.  The biggest of these issues is that of parallel works-in-progress.  We are constantly working on issues with the code, resolving them (hopefully), then testing and iterating changes and fixes back into the code.  While these feedback cycles occur, the code is in a work-in-progress state, however, we can’t serialize the process.

Having our developers sit around twiddling their thumbs while the code is tested and vetted simply isn’t an option.  So they work on other issues while the feedback is generated from earlier work.  If you are only working on the trunk, this means there is always half-baked code in there.  When the time comes to cut further development and release, sometimes code isn’t fully baked but is too difficult to track and back out.  Thus bugs in the field are born.

So there is the appeal of distributed version control systems.  Branching allows you to track individual changes in their own branch and “graduate” them to the trunk after they have been vetted.  Not only that, if you want to test a fix in isolation from other trunk changes, the branch allows you to do this by implementing the fix on top of just the last released version of the code, without any interim work (vetted or not) to gum up the works.  While this kind of targeted development is sometimes more effort than it is worth (it means you have to track a lot more interim versions of the build and which particular problems they solve), it can be worthwhile a lot of the time.  If branches are low-cost (at merge-time as well as branch-time), then this model becomes possible.

That being the goal, let me say that that’s a theory for us.  Others whose posts I’ve read say the model works and the appeal is enough for us to investigate, but I personally haven’t seen this in practice yet.

In both Git and Mercurial (as well as the other contenders), branching is not only simple, it’s the only means of development.

Let me step back from that statement and explain what I mean.  In a DVCS, there is the concept of the repository and the working copy, just like in Subversion.  The repository contains the history of changes, and the working copy is the current state of the files, whether that is from the last revision in the repository or some other point, with or without your own local modifications.  The system tracks your changes to the working copy, allows you to go back to other points-in-time and generally handles change management on those files.

In Subversion, the repository is usually centralized somewhere on the network and is not only authoritative, it is the only repository for that code.  Sure, you can check in the same files somewhere else, but there is no system for keeping that repository in sync with the central repository, unless you look at distributed enhancements to Subversion, which I have not.

In a DVCS, there can be and always is more than one repository as soon as more than one developer is involved (and usually even before that).  The difference is that the working copies are almost inevitably tightly-coupled with a copy of the repository.  This means that the repository is local to your disk and resides alongside the working copy.  The upshot of this is that your working copy/repository is usually larger than the simple working copy of the centralized VCS, but in trade, repository operations are usually far faster.  More on the impact of this distinction later in my series.

The way this works is that there are mechanisms to keep your repository in sync with other repositories by pushing and/or pulling changes from one repository to another.  A typical workflow might be to have an “authoritative” or “build” repository that lives remotely, from which the developers copy theirs.  While the developers work, they can commit their changes to their local repository.  A commit does not automatically synchronize to other repositories.  Then, as a piece of work concludes, the work can be tested locally, approved, then pushed to the central repository from which other developers can then receive the changes by pulling.

Getting back to my point about branching being the regular mode of operation in this model, each repository in this case can be viewed as its own branch.  The reason I say this is because each copy of the repository is not required to synchronize after a change is committed.  In Subversion, once a commit is made, no other changes can be committed by other developers without them first updating their working copy and resolving any conflicts that arise.

This means that, in Subversion, for a given directory path there is only ever one line of commits (barring discussion about explicit branches, which are different directory paths).  Each subsequent commit contains all of the changes from every commit prior to it.

In a DVCS, concurrent changes can be committed to the various developers’ separate repositories, and no communication happens between them unless the developers initiate it manually.  This means that there are necessarily divergent lines of development which do not contain the same set of changes, even while each copy of the repository only sees its own straight line of development.

These unsynchronized copies of the repository are therefore each their own branch of development, which may continue unabated without having to be synchronized with the other branches.  In fact, nothing says that they need be synchronized ever again, although in practice they will usually be synchronized fairly frequently.

This kind of branching is called “anonymous branching” in Mercurial because each branch exists without any explicit name to mark it as such.  Two developers may separately develop branches that both think they are the “default” line of development.

At some point these changes will usually be synchronized.  When that happens, there is only one thing that the system can do…it must track two (or more) separate lines of changes that are not merged.  This is where the concept of “heads” comes in.  Each repository must store the branches of development which result in a different state of what is meant to be the same set of files at the ends of each branch.  Each branch then has its own head, the final state of files in that branch.

As a hypothetical aside, the system could force one of the developers to accept the others changes only into their working copy, resolve any conflicts, then update their single line of development with the merge.  By keeping the other changes out of the repository until they are merged, this could keep a single line of development in the repository, much like Subversion.  Concurrent development could continue without synchronization of this sort, but once synchronization occurred, there would be no branches.

However, this would be less flexible than what the DVCS systems actually allow.  By tracking separate branches with their own heads, synchronization can take place and separate lines of development can be shared between developers without requiring any sort of merge at synchronization time.  This means branched work can be shared between developers without requiring the work to be integrated.  Developers can collaboratively work on different development lines by synchronizing repositories and switching their working copy between the branched lines.

While there are other branch management tools in both systems, this fundamental form of branching is so intrinsic to git and Mercurial that they need to handle merging well by necessity because it happens frequently.

While this is a requirement for such systems, it is not an explanation of why merging is better/faster/easier/some combination than Subversions.  That’s a matter of implementation.  In practice, it is better.  Why?  I have no idea.  I haven’t played with it enough to know the differences and I don’t understand it well enough in Subversion in the first place to offer a rationale.  I’m sure that a large part of it is that these systems track file moves and renames explicitly and better than Subversion does.  Otherwise, I’m at a loss.  But it works, it really does.

Objectively, merging just works most of the time.  There is nothing to prevent you from introducing logical inconsistencies into your code by merging, and detection of actual file conflicts doesn’t prevent that.  However, in practice, that’s what testing (such as unit testing) is for, and most of the time the code works if your developers are working on logically separate portions of your code.  There are fewer merge options, which lowers the required knowledge and incidence of operator error.  Merges tend to go off without a hitch.

Of course, merges have to be done explicitly and then committed and pushed/pulled to other repositories, so there is a bit more elbow-grease to be applied in that respect, but it remains simpler than merging in Subversion by a great degree.

So, to recap, the motivation for us to look at these systems is to enable collaborative, multi-branch lines of development.  This will hopefully allow us to target fixes and features in a more fine-grained manner, with fewer interaction effects of work-in-progress.  It will also give us more control over released code, as branches must graduate to the main line of development.  We’ll see how these advantages pan out in practice as we get more comfortable with them.

Next time I’ll cover useful links for understanding and comparing git and Mercurial.

Permalink | Leave a comment  »

]]>
Thu, 08 Oct 2009 21:18:00 -0700 TortoiseSVN/Redmine integration http://transfermodeawesome.posterous.com/2009/10/tortoisesvnredmine-integration.html http://transfermodeawesome.posterous.com/2009/10/tortoisesvnredmine-integration.html Spent the day working on integrating TortoiseSVN commit logs with Redmine issues.  Some cool stuff is possible.  This post is an adaptation of my status update for this task in my list, so it may not be completely coherent, but here it is:

Accomplished so far:

TortoiseSVN integration:
  1. Added bugtraq:url and bugtraq:logregex properties globally to repository folders
  2. Added webviewer:revision and webviewer:pathrevision properties globablly to repository folders
  3. Tested TortoiseSVN Redmine integration plugin

Redmine settings:

  1. Changed server repository settings so "fixed" keywords close and mark 100% done referenced issues

bugtraq folder properties

Configuration of bugtraq folder properties is described at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html and http://stackoverflow.com/questions/516542/integrate-tortoisesvn-with-redmine.
These are properties which can be supported by any subversion client which chooses to implement them.  TortoiseSVN supports them.
The bugtraq:logregex property tells the client how to recognize a reference to an issue ID within the comment of a log.  It's value is a pair of regular expressions which tell the client how to recognize a reference to an issue ID and then how to extract the ID number from that phrase.
The pair of regular expressions used in this case is:
([Cc]loses|[Ii]ssue[Ii][Dd]|[Rr]eferences|[Rr]efs|[Ff]ixes(\s[Bb]ug)?)\s?#(\d+)
\d+
This allows the use of the following phrases to refer to an issue ID:
  • References: refs,references,IssueID
  • Fixes: fixes,closes,Fixes Bug
Using any of these phrases in a commit log message will cause TortoiseSVN to recognize it as an issue ID.  Tortoise will highlight the phrase in the commit to let you know it has been recognized.  Then, after committing, when you check the commit log that message will show up with a link for the ID number.  The bugtraq:url property determines how that id is turned into a link.  In this case, it points to the redmine server.  There is also a new column in the commit log which is just for issue ID so you can easily see issue ids in the log.
A log message may reference more than one issue id.  Each reference has to use the phrasing above.
The properties are set on folders.  In our case, they are set uniformly across all folders in the repository.  New folders do not get properties such as this created by default, but as long as most folders have them, it should still work.
It should still work because Tortoise examines the current working copy folder for the properties, and if not found, keeps looking higher in the working copy tree.  As long as one of the parent folders in the checkout has the properties, it will behave correctly.  Since they are currently set on every folder, the likelihood of the properties being found is high.
However, since checkouts are usually done at the project level (just for clarity: project not project group), then the properties need to be set at least at that level.  Therefore, any new project will need to have the properties set on it.  This can be done either explicitly on the project folder when it is created (preferably recursively after subfolders have been created as well).  Or it may be set recursively at a higher level in the directory tree.  This would need to be done either right after the project creation or perhaps by a periodic process sometime later.  A database commit hook could also enforce the setting of the property at the project level, but that would need development.

webviewer folder properties

The webviewer:revision property allows the TortoiseSVN client (and other clients) to relate the log back to a web-based view of the repository.  In this case, it relates to the repository view of Redmine.
When viewing the commit log for a file or folder in Tortoise, right-clicking the context menu when this property is set provides a "view revision in webviewer" context menu entry.  Clicking this entry takes you to the revision's changeset in redmine.  This is useful to see a more Redmine-integrated view of the repository than provided by TortoiseSVN.
The webviewer properties are set on folders similarly to the bugtraq properties and follows the same rules.
There is another property that allows you to go from the TortoiseSVN commit log to the Redmine view of a particular item (file or folder) at a particular revision.  That property is the webviewer:pathrevision property.  As mentioned above, it has been set.

TortoiseSVN Redmine integration plugin

TortoiseSVN issue tracker integration plugins are discussed under the heading Getting Information from the Issue Tracker at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html.
TortoiseSVN integration plugins are modules that allow TortoiseSVN to retrieve an issue list from the issue tracker itself.  This makes it easier to remember the issue id associated with the changes being checked in.
Integration plugins are TortoiseSVN-specific and must be installed on the same machine as TortoiseSVN.  This means the plugin must be installed on each developer's machine.  It also means that other clients (such as the Visual Studio AnkhSVN plugin) do not get this capability as well.  This makes it easier to use Tortoise to do checkins, but is by no means a reason to abandon other clients.
The TortoiseSVN Redmine integration plugin can be obtained from http://code.google.com/p/chrismckee-project-bay/wiki/REDMINETSVN.
The Redmine plugin adds a button to the commit dialog in the upper right-hand corner.  The button is tied to the Redmine project URL by the configuration of the plugin.  Each Redmine project you are working on must have a configuration in the plugin in order for task lists to be available.
Because the plugin is sensitive to the project location of the working copy, it only shows those issues related to the project being checked in, which greatly simplifies things.  So the extra configuration is warranted and productive.
To configure the plugin, follow the directions at http://code.google.com/p/chrismckee-project-bay/wiki/REDMINETSVN#Setup.  The working copy directory is associated with the plugin and the project Atom feed from the issues list page for the project.  This configuration is done in the TortoiseSVN settings menu.  See the URL for full directions.

Redmine repository settings

The global settings for repositories in Redmine are at /redmine/settings">http://<your redmine server name>/redmine/settings under the Repositories tab.
By default, Redmine can respond to messages in the commit logs of checkins.  It automatically creates associations from an issue to a revision changeset when the issue is references in the commit log.  This makes it easier to keep track of the actual work of a task and changes made.
It can also take the action of closing an issue as well as setting the done percentage by responding to certain keywords in the commit log.
These features are similar to the earlier discussed TortoiseSVN capabilities associated with commit log keywords, but are implemented and configured separately.  The Redmine keyword recognition is performed separately from TortoiseSVN's.
There are two settings in the settings page referenced above.
The first is Referencing Keywords, which tell Redmine to make a link both in the issue as well as from the repository view.  The link in the issue refers to the repository change revision, and the link in the repository refers to the issue.
The second is Fixing keywords, which tell Redmine to set the status of the referenced issue as well as the Done percentage.
The current configuration recognizes the same words used in the TortoiseSVN integration.  refs, references, and IssueID make references.  fixes, closes, fixes bug change the status to Closed and set the Done percentage to 100%.  The ID itself must still be referenced by a pound-sign directly in front of the number such as #25.  Note that when an issue is closed, the link from the repository view still exists but has a strikethrough to indicate the closed status.

Permalink | Leave a comment  »

]]>
Wed, 07 Oct 2009 21:21:00 -0700 Yet more Subversion repository polling headaches http://transfermodeawesome.posterous.com/2009/10/yet-more-subversion-repository-polling.html http://transfermodeawesome.posterous.com/2009/10/yet-more-subversion-repository-polling.html Either there is something very wrong with the way our repository is set up (i.e. my fault) or there is something wrong about the polling model for detecting changes in the repository.
This is the second or third time I’ve run into this issue.  Granted, we have not had the most fastidious design for our repository, however, I can’t believe that what we are doing on this small scale is so outside the pale of what other, much larger organizations (such as open-source hosters) are doing.  I just don’t think we’re that special.
The problem manifested itself today in the form of hundreds of authentications per second against Active Directory from a particular account and server.  The server is our Subversion repository server, naturally, and the account is the special build server account set up to monitor and build from our product locations in the repository.
The tide was sustained over a wide range of time and seemed to be contributing to visible load on the domain controller.  If not harmful, this is at the least embarrassing and annoying for our build infrastructure, which I’m very much invested in.  Nothing I know should be causing this kind of traffic, and if it is a consequence intrinsic to the system, I should find a way to make it less demanding.
I’ve run into similar issues with other tools before.  Evidently, polling a repository for changes is demanding on a repository.  We had an application called SVN monitor which was very nice.  Every time a commit was made to the repository, a notification would pop up from the system tray giving you the details, which you could then inspect with a pretty nice repository browser.  The polling interval could be configured as well.
Unfortunately, we would see enormous spikes in CPU usage on the SVN server when a few users would be polling for changes.  Limiting the number of polled locations and frequency of polling helped performance but greatly hampered the usefulness of the tool.  We eventually replaced it with the repository view from Redmine.
Back to tracking down the current issue.  The SVN server (VisualSVN) is configured for secure connections with Windows Authentication.  The authentication requests to AD coming from this server are responses to SVN clients making requests of the server.  Turning off the SVN server verified that it was indeed the source of the authentication requests.  There were only two servers configured to use that poll the subversion server using the account in question…Redmine and TeamCity, our build server.
The Redmine repository view does take some time (and presumably therefore, effort) to refresh its view.  It uses the subversion command line tools to do so.  However, it should only refresh when you visit the page.  So this isn’t a likely culprit unless something is very wrong.
TeamCity, on the other hand, is constantly polling to show you what changes might be pending for the next build.  This was the likely culprit.  Shutting it down quickly killed all of the authentication requests.  That was the winner.
However, what to do about it is an issue.  Obviously, it isn’t necessary to poll every 60 seconds for every VCS root in TeamCity, but there has to be a happy medium.  I reduced the polling interval globally to 10 minutes, which definitely helped.  There are only four VCS roots, and the TeamCity vcs log shows that they are polled individually each minute (by default)…so why the hundreds of authentication requests.  Something about the way TeamCity polls must break up the poll into lots of small requests, each requiring authentication.  This is what is nailing our domain controller.
Aside from reducing the polling interval, I’m not sure what else there is to do at the moment.  I haven’t posted a question on their support forum, but that’s on tap.  Perhaps there is more to come.

Permalink | Leave a comment  »

]]>
Wed, 12 Aug 2009 23:57:00 -0700 Editing Subversion log messages after the fact and the pre-revprop-change hook http://transfermodeawesome.posterous.com/2009/08/editing-subversion-log-messages-after.html http://transfermodeawesome.posterous.com/2009/08/editing-subversion-log-messages-after.html Having gotten Subversion integration working in Redmine, I wanted to add an issue reference to a log message where I had fixed the issue.
When I used TortoiseSVN to try to make the edit however, I got a nasty message saying I couldn’t change the log because there was no pre-revprop-change hook implemented at the server.  Ouch!
Apparently this is done intentionally so that you can’t go rewriting (presumably important) history willy-nilly.  There is no versioning on the version control properties themselves, so apparently log message and other revision property edits are destructive.
However, I’ve needed to do this more than once, so as the judge said, I’m going to allow it.
Now, how to implement it?  This article from StackOverflow is useful:
http://stackoverflow.com/questions/197224/what-is-a-pre-revprop-change-hook-in-svn-and-how-do-i-create-it

Permalink | Leave a comment  »

]]>
Wed, 12 Aug 2009 21:58:00 -0700 Getting Subversion Repository access working with Bitnami Redmine 0.8.4 stack http://transfermodeawesome.posterous.com/2009/08/getting-subversion-repository-access.html http://transfermodeawesome.posterous.com/2009/08/getting-subversion-repository-access.html I’ve been playing with Redmine for some time and am still impressed with the basic issue tracking and wiki functionality, but since starting to work with issues, I haven’t been tying them to work done in the source code repository.
Looking to remedy this, I set up the repository access details according to the project settings page.  This involved naming the Source Code Management system (Subversion), the root URL for the project, and a suitable login and password.
I did all this correctly, yet when I went to the Repository page for the project, all I got was an error saying the revision was not accessible.
A bit of research didn’t come up with a direct solution, but I did come to have a suspicion that worked out to be true.
First, I found out that the repository functionality in Redmine relies on the command-line subversion client.  This didn’t come with the Bitnami Redmine Stack (I’m on Windows, btw), so I installed it and rebooted to make sure the PATH environment variable got set properly.
After this, I ran the svn command as a test:
svn info https://my.repository.com/root
This prompted me to store the server credentials, which I accepted permanently.  This was definitely something I realized that I now how to do from the service account for Redmine.
Redmine, however, was configured to use the local system account, which doesn’t have an interactive login.  While I could have changed the service logon, I am loathe to do that to a running system.  Who knows what permissions will break.
Luckily, I remembered an old trick from the Sysinternals guys: psexec.
psexec allows you to do a telnet-like session to your own or another machine, including setting the user credentials.  It also has a special ‘-s’ switch for logging in as the system account.
A few tries got me to the magic incantation:
psexec –s –i cmd.exe
This got me an interactive window running the command interpreter as the local system account, which I verified by checking the environment variables.
Running the svn command allowed me to store the server credentials under the system account.
However, my ordeal was not over yet.  Fortunately, reading the Redmine Guide had alerted me to the fact that the first time you run the repository view, it takes a long time to index the repository into the database.  They weren’t kidding.  My browser finally timed out waiting for it to complete (but I knew some progress had been made since it was actually taking time this time around). Watching the server’s load with Process Explorer (another great Sysinternals tool) I could see it peak, sustain, trough and peak again over and over.
When it finished, I reloaded the web page, and voila!  Redmine repository happiness with Bitnami Redmine Stack as a local system service on Windows.

Permalink | Leave a comment  »

]]>
Fri, 19 Jun 2009 14:31:00 -0700 Good excuses to not use version control http://transfermodeawesome.posterous.com/2009/06/good-excuses-to-not-use-version-control.html http://transfermodeawesome.posterous.com/2009/06/good-excuses-to-not-use-version-control.html From a thread on StackOverflow:

Good excuses NOT to use version control

This question may seem backwards to all logical reasoning, but I encountered a team member who was working on a side project out of the main tree, and had decided ( rephrased )
I'm the only developer, we don't need version control, that's stupid
Now personally, the idea horrifies me, and I can't for one justify it.
So now my stance is clear, I want some legitimate answers why somebody can excuse themselves from using version control. The default answers will of course be "there is no excuse".
Not what I want to see. If you can't see an excuse, then just don't post. ( Feel free to downmod excuses others post that are illegitimate/bad and give reasoning )

72 Answers

There are no good reasons not to use version control. Not one.
answered Sep 25 at 10:32

I can think of one:

I'm the only developer, we don't need version control, and I'm stupid
answered Sep 25 at 10:35

Permalink | Leave a comment  »

]]>