This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 77259 - Subversion Checkout places files one level deeper than expected
Summary: Subversion Checkout places files one level deeper than expected
Status: RESOLVED DUPLICATE of bug 76410
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Subversion (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: issues@versioncontrol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-01 20:56 UTC by esmithbss
Modified: 2006-06-02 09:58 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description esmithbss 2006-06-01 20:56:40 UTC
Assume you have a subversion repository with the following structure:

/repos
   |
   + Project_1
        |
        + branches
        + tags
        + trunk
             |
             + File_1
             + File_2

where development is performed against the HEAD version in /repos/Project_1/trunk.

Using the subversion command line tools or other tools like TortoiseSVN, KDESVN,
RapidSVN, Subclipse (for eclipse), etc..., when you checkout files, you specify
the trunk as the repository location to be checked out, and the HEAD as the
version.  If you specify that it should be checked out to \Projects\Project_1
you will get a checkout where File_1 and File_2 are located at
\Projects\Project_1\File_1 and \Projects\Project_1\File_2.  This is standard
behavior (as demonstrated by the Subversion command line tools and the
subversion manuals).

When using the Subversion plugin to NetBeans, this same checkout scenario
results in a folder "trunk" being placed in \Projects\Project_1 such that the
checked out file locations are \Projects\Project_1\trunk\File_1 and
\Projects\Project_1\trunk\File_2.  This behavior is non-standard and should be
corrected to the standard behavior.
Comment 1 Tomas Stupka 2006-06-02 09:58:18 UTC

*** This issue has been marked as a duplicate of 76410 ***