Type:
Feature
Priority:
Critical Critical  
State:
Fixed
Subsystem:
Unknown
Reporter:
Gunnlaugur Thor Briem (gthb) Send Email
Assignee:
Olesya Smirnova (lesya) Send Email
Affects:
Agra EAP (3654)
Fixed in:
Teamcity 3.0 (Benares, 5985)
Created:
21 months ago (15 Feb 2007 14:00)
Updated:
13 months ago (04 Oct 2007 14:11)
Votes:
1
Resolved:
—
JIRA source:
TW-1738
No attachments

In our environment, we have a single huge TFS source tree, and create smaller workspaces by cloaking away parts of the tree.


Accordingly, it is desirable to have TeamCity fetch only that workspace, i.e. those parts of the tree needed for a build of the given project, so that the fetch doesn't take too much time and doesn't take too much space on the build agent.


I've done this in my project by manually typing in several different source code roots, all from the same TFS tree. There ended up being 13 of them, because my project's solution file references projects outside its VCS subtree (with relative paths starting with ../).


This is laborious to do manually, and has to be done separately for each TeamCity project definition.


The "partial source trees" requirement could be supported in a more usable manner either by:


1) making TeamCity support cloaking, in the way that TFS workspaces do (and preferably accepting a workspace definition from the local computer, since we already have our workspaces defined on our workstations)


2) making TeamCity infer the other TFS roots from the solution file. We would create one TFS root, to the directory where the solution file is, and identify that solution file as the build definition. TeamCity would then automatically create VCS roots for those project files in the solution file that exist outside the solution file's root directory. They are specified with relative paths in the solution file, so this ought to be a fairly well-defined task. VCS roots may also be needed for library references within those project files, whose relative paths also resolve within the source tree. The user could then modify this automatically-inferred set of VCS roots if needed; the common case would at least be simplified.


The disadvantage of approach 2), and my current manual approach, is that with multiple VCS roots from the same TFS tree, changesets are incorrectly displayed as split in TeamCity if they span multiple VCS roots. E.g. changeset 25634 affects files that are all in the same TFS tree but appear in three different VCS roots in TeamCity, so that TeamCity incorrectly says there are three changes (all with the same check-in comment).


With approach 1), the cloaking (i.e. the workspace definition) could also be inferred automatically from the solution file, by pruning away parts of the tree that are *not* used in the solution. But really that's a feature that we should have outside TeamCity, in the TFS tools, so TeamCity should only need to import the workspace definition automatically, if that


Environment: Running in Windows, against TFS as VCS


Issue wasresolved

  • Gunnlaugur Thor Briem (gthb) Send Email
    21 months ago (15 Feb 2007 14:13)

... uh, if that approach were taken. :)

  • Gunnlaugur Thor Briem (gthb) Send Email
    20 months ago (23 Feb 2007 14:13)

Can't decide who should do it? :)


A quicker way for you to improve usability would be to allow us to enter multiple root paths in one page ... even by just changing the root path textbox to a multi-line textarea, where we enter one root path per line. That way one could paste the directory list in, e.g. from the workspace definition; this would already be much less tedious, and would be an easy change to make. (Approaches 1 and 2 would be nice too, though :) )

  • Gunnlaugur Thor Briem (gthb) Send Email
    20 months ago (21 Mar 2007 14:50)

Status is "In Progress" but Fix Version is "Backlog" ... will you do this in the Agra release, or later?


This is really desirable for us; our source tree is enormous and has a lot of unrelated projects, so we need to prune it for individual projects to (a) speed up builds and (b) avoid unnecessary notification emails for changes that are not really related to a build failure. This pruning is currently very, very laborious, and I imagine we are not the only ones facing this. Any of the above improvements would help a lot.

  • Kirill Maximov (maxkir) Send Email
    20 months ago (21 Mar 2007 20:20)

Sorry, this is not planned for Agra. This is new feature, and we're currently in bugfix stage. We'll consider to implement this in future versions of TeamCity.

Old New
Gunnlaugur Thor Briem (gthb) - 13 months ago (04 Oct 2007 14:11)

JetBrains Tracker revision #2008 [13-Nov-2008 11:56] (version #56) Copyright 2007-2008 JetBrains s.r.o.