DirectoryRequest.cs :  » Source-Control » NetCvsLib » CVS » Requests » C# / CSharp Open Source

Home
C# / CSharp Open Source
1.2.6.4 mono .net core
2.2.6.4 mono core
3.Aspect Oriented Frameworks
4.Bloggers
5.Build Systems
6.Business Application
7.Charting Reporting Tools
8.Chat Servers
9.Code Coverage Tools
10.Content Management Systems CMS
11.CRM ERP
12.Database
13.Development
14.Email
15.Forum
16.Game
17.GIS
18.GUI
19.IDEs
20.Installers Generators
21.Inversion of Control Dependency Injection
22.Issue Tracking
23.Logging Tools
24.Message
25.Mobile
26.Network Clients
27.Network Servers
28.Office
29.PDF
30.Persistence Frameworks
31.Portals
32.Profilers
33.Project Management
34.RSS RDF
35.Rule Engines
36.Script
37.Search Engines
38.Sound Audio
39.Source Control
40.SQL Clients
41.Template Engines
42.Testing
43.UML
44.Web Frameworks
45.Web Service
46.Web Testing
47.Wiki Engines
48.Windows Presentation Foundation
49.Workflows
50.XML Parsers
C# / C Sharp
C# / C Sharp by API
C# / CSharp Tutorial
C# / CSharp Open Source » Source Control » NetCvsLib 
NetCvsLib » CVS » Requests » DirectoryRequest.cs
// DirectoryRequest.cs 
// Copyright (C) 2001 Mike Krueger
// comments are taken from CVS Client/Server reference manual which
// comes with the cvs client (www.cvshome.org)
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License
// as published by the Free Software Foundation; either version 2
// of the License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
//
// As a special exception, if you link this library with other files to
// produce an executable, this library does not by itself cause the
// resulting executable to be covered by the GNU General Public License.
// This exception does not however invalidate any other reasons why the
// executable file might be covered by the GNU General Public License.

namespace CVS.Requests{
  
  /// <summary>
  /// Additional data: repository \n. Response expected: no. 
  /// Tell the server what directory to use. The repository should be a directory 
  /// name from a previous server response. Note that this both gives a default 
  /// for Entry and Modified and also for ci and the other commands; normal usage 
  /// is to send Directory for each directory in which there will be an Entry or 
  /// Modified, and then a final Directory for the original directory, then the 
  /// command. The local-directory is relative to the top level at which the 
  /// command is occurring (i.e. the last Directory which is sent before the command); 
  /// to indicate that top level, `.' should be sent for local-directory. 
  /// </summary>
  /// <example>
  /// Here is an example of where a client gets repository and local-directory. Suppose that there is a module defined by 
  /// moddir 1dir
  /// 
  /// That is, one can check out moddir and it will take 1dir in the repository and check it out to moddir in the working directory. Then an initial check out could proceed like this: 
  /// C: Root /home/kingdon/zwork/cvsroot
  /// . . .
  /// C: Argument moddir
  /// C: Directory .
  /// C: /home/kingdon/zwork/cvsroot
  /// C: co
  /// S: Clear-sticky moddir/
  /// S: /home/kingdon/zwork/cvsroot/1dir/
  /// . . .
  /// S: ok
  /// 
  /// In this example the response shown is Clear-sticky, but it could be another response instead. Note that it returns two pathnames. The first one, `moddir/', indicates the working directory to check out into. The second one, ending in `1dir/', indicates the directory to pass back to the server in a subsequent Directory request. For example, a subsequent update request might look like: 
  /// C: Directory moddir
  /// C: /home/kingdon/zwork/cvsroot/1dir
  /// . . .
  /// C: update
  /// 
  /// For a given local-directory, the repository will be the same for each of the responses, so one can use the repository from whichever response is most convenient. Typically a client will store the repository along with the sources for each local-directory, use that same setting whenever operating on that local-directory, and not update the setting as long as the local-directory exists. A client is free to rename a local-directory at any time (for example, in response to an explicit user request). While it is true that the server supplies a local-directory to the client, as noted above, this is only the default place to put the directory. Of course, the various Directory requests for a single command (for example, update or ci request) should name a particular directory with the same local-directory. Each Directory request specifies a brand-new local-directory and repository; that is, local-directory and repository are never relative to paths specified in any previous Directory request. 
  /// </example>
  public class DirectoryRequest : AbstractRequest
  {
      string localdir;
      string repository;
    
      public DirectoryRequest(string localdir, string repository)
      {
          this.localdir   = localdir;
          this.repository = repository;
      }
    
    public override string RequestString {
      get {
        return "Directory " + localdir + "\n" + repository + "\n";
      }
    }
    
    public override bool IsResponseExpected {
      get {
        return false;
      }
    }
  }
}
www.java2v.com | Contact Us
Copyright 2009 - 12 Demo Source and Support. All rights reserved.
All other trademarks are property of their respective owners.