You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(22) |
Oct
(41) |
Nov
(52) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(15) |
Feb
(8) |
Mar
(4) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(25) |
Nov
(11) |
Dec
(20) |
2005 |
Jan
(32) |
Feb
(16) |
Mar
(4) |
Apr
(4) |
May
(2) |
Jun
(16) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Gerald E. <gn...@f2...> - 2003-09-27 11:25:49
|
At 22:43 26/09/03 -0700, Clayton Harbour wrote: > >One other thing I noticed in the file handlers when both sending and > >receiving text files is that they make a physical copy of the file on >the > >hard disk (to simplify the process of converting linefeeds betwen >windows > >and *nix). This seems particularly silly if you are using #cvslib >under > >linux/mono where obviously no translation needs to take place. I see >no > >reason why this couldn't always be done in-line which would save on the > > >extra disk activity. Low priority I know compared to the other items >that > >need doing, but worth doing at some point. > >I did not think about the line endings, this was one of the things I >assumed was being handled magically by the framework :-). I think the >temp files have two purposes then, one for the line endings and the >other to keep the memory footprint small if the client is bringing down >some larger files. Alas, the current code allocates a single block of memory and reads the entire file into it before sending it, and similarly when receiving files. So this will need changing to avoid problems supporting large files. >Still I agree with you about performance, although >it would be a low priority item. > >How does this sound: before the server sends down a file it sends down a >byte count. We do a test to see if this byte count is above a certain >threshold (probably on a per system basis, grab the memory installed and >only use a reasonable fraction of that) we spool, if not then we use an >in memory stream. It should just be a matter of using a buffered stream. I'm not sure what buffering the network stream class provides, but it should be possible to provide buffering (to minimise network packets) without the need to spool the file to disk. The fine details can be looked into when someone implements the change. >If that works for you then we can add it to a bug/feature request so we >remember it exists. Yes, both the removal of the need to use a temporary file and the removal of allocating a single block of memory for the entire file need to be added. Makes sense if both of these are addresed together. Gerald. |
From: Clayton H. <cla...@sp...> - 2003-09-27 06:13:54
|
Hi Gerald, Thanks again for help on the tests! Responses inline. > >3 new test files attached for Streams and FileHandler directories. Committed. =20 >I have a slight concern with CvsStream in that it not only contains a=20 >Stream class but it also inherits from Stream. >CvsStream overrides most of the Stream members and calls the same function=20 >on the contained Stream. However it does not override all of the Stream=20 >members, so if someone was to call one of these it would act on the=20 >inherited Stream and not the contained Stream, which is not what one would=20 >expect. That might be a bad thing. I think that we can minimize this when we start converting the public classes to internal. I have the nant builds working again and just need to get the unit tests I broke back in the good. After that maybe we can start looking at what needs to be made internal. >The easiest solution would be for CvsStream not to inherit from Stream. I=20 >have tried this and everything still compiled, but I don't know if this >will cause any problems for anyone else, or if the inheritance is there for=20 >a good reason? I am not aware of a reason. If it is an easy change to remove the inheritance then maybe we should explore that. It might be a good idea to add a few more tests for different protocols (ext/ssh) first on the off chance that had something to do with the design. Just a thought, no evidence to back that up :-). >One other thing I noticed in the file handlers when both sending and=20 >receiving text files is that they make a physical copy of the file on the=20 >hard disk (to simplify the process of converting linefeeds betwen windows=20 >and *nix). This seems particularly silly if you are using #cvslib under=20 >linux/mono where obviously no translation needs to take place. I see no=20 >reason why this couldn't always be done in-line which would save on the >extra disk activity. Low priority I know compared to the other items that=20 >need doing, but worth doing at some point. I did not think about the line endings, this was one of the things I assumed was being handled magically by the framework :-). I think the temp files have two purposes then, one for the line endings and the other to keep the memory footprint small if the client is bringing down some larger files. Still I agree with you about performance, although it would be a low priority item. How does this sound: before the server sends down a file it sends down a byte count. We do a test to see if this byte count is above a certain threshold (probably on a per system basis, grab the memory installed and only use a reasonable fraction of that) we spool, if not then we use an in memory stream.=20 If that works for you then we can add it to a bug/feature request so we remember it exists. Cheers, Clayton |
From: Clayton H. <cla...@sp...> - 2003-09-26 10:58:20
|
Hi, I made some changes to the nant build files last night to get the build working on linux and mono. Currently I have pretty much everything back up and running with the exception that you have to modify a hard coded base directory. Please modify this locally until I can update it. If you are interested in hacking on mono I have also checked in an eclipse project file. Eclipse does not provide much support, however you can google for a c# plugin that helps with syntax highlighting. You will need to use nant to compile (binaries in the /tools folder). Happy hacking! Clayton |
From: Clayton H. <cla...@sp...> - 2003-09-23 15:22:49
|
Hi, =20 I have a first cut of the cvs revision (sticky-tag) checkout in the nant cvs repository. Unfortunately I introduced an issue with file times being set to the current date and time which I will try to resolve this week. There may be other issues as this is under heavy development but it is there. If you would like to try it you can specify a checkout using the following: =20 <?xml version=3D'1.0'?> <project default=3D"checkout.nant.override"> <target name=3D"checkout.nant.override"> <cvs-checkout module=3D"nant" =20 cvsroot=3D":pserver:ano...@cv...:/cvsroot/nant" destination=3D"E:\test" password=3D""> <options> <option name=3D"sticky-tag" value=3D"your_favorite_nant_version" /> <option name=3D"override-directory" value=3D"nant_favorite_version" /> </options> </cvs-checkout> </target> </project> =20 As you might have noticed there is also support to override the module directory in a checkout as well. I found a bug this morning with an update using the override directory but the checkout works fine. =20 As always feedback any feedback is appreciated :-). =20 =20 Cheers, =20 Clayton |
From: Clayton H. <cla...@sp...> - 2003-09-22 14:18:17
|
Gerald, I ran the entire test suite (before I just ran the internal class tests) against this solution and ran into a problem with the configuration loader test (class cast exception). I have not had a chance to track it down yet and I don't think it would be a deterrent, just thought I would flag it. Clayton -----Original Message----- From: Clayton Harbour=20 Sent: September 22, 2003 6:17 AM To: Gerald Evans Cc: sha...@li... Subject: [Sharpcvslib-developers] RE: Class visibility question Gerald, I have cc'd the #cvslib list. =20 Some very good questions and something I have thought about a (tiny) bit. Responses below. -----Original Message----- From: Gerald Evans [mailto:gn...@f2...]=20 Sent: September 22, 2003 4:51 AM To: Clayton Harbour Subject: Class visibility question Clayton, >1) Is there any documentation on the interface that sharpcvslib provides=20 >(or will provide) for developers wishing to make use of it in their >projects? C: Yes, there is some documentation (the API docs). There is not a lot there and it is a little mixed with the methods that we might want to be internal but it is a start. =20 >2) Is the intention to expose the minimum necessary to provide cvs support=20 >for other projects, or do we want to provide access to some/all of the=20 >internal 'helper' classes as well? C: The minimum necessary definitely. I see the Command, Misc (probably only pieces...and maybe with a better name) and Client namespace being the ones requiring he >3) As far as I can see, at the moment all classes are public so any user of=20 >the DLL has access to all of these classes. It users do start using the=20 >'helper' classes then this would make it more difficult for us to change=20 >them later on if we needed to, or would make it more difficult for users to=20 >upgrade to a later DLL. C: I agree, we should lock it down. >4) As the unit tests are in a separate DLL, does this mean that they would=20 >not be able to test the 'helper' classes if they were marked 'internal', or=20 >is there some way around it with multi-file assemblies? C: That is true, if the helpers are compiled separately from the main assembly then it would be impossible to test the internal helper methods. I have been thinking of a workaround for this which would be to build the test and source all into one assembly (the test assembly). I have attached the files to make this change and commented them with: // TODO: Change to internalize helpers with the type of change. If you like this I can commit what I have and then we can hash over the details of what needs to be internal and what we need to expose. Let me know what you think. Perhaps it is still a bit early to start worrying about the above, but was=20 just wondering if you had any specific intensions towards class visibility. Gerald. |
From: Clayton H. <cla...@sp...> - 2003-09-22 13:40:17
|
Hi, Actually if you are comfortable working on linux that would be awesome. One of the short term goals is to test the library on mono (http://go-mono.com). If you would like to try to get an environment running on linux and help with the tests that would be great. The purpose of the library is to provide a backbone for cvs support for...whatever. In addition to this backbone support I would also like to provide an implementation for the following two clients: 1) A command line client (currently named scvs to keep down on name clashes while developing, this will change to cvs) 2) A vs.net plug-in along the lines of the ankh project for subversion (http://ankhsvn.tigris.org/faq.html) Another more ambitious goal is to provide a layer over top of the library that would make it possible to interface with a VSS, subversion and CVS repository. I see that as a ways off though. Clayton -----Original Message----- From: Alexander A.Danilov [mailto:al...@us...]=20 Sent: September 22, 2003 2:25 AM To: dr...@us... Subject: RE: c# developer knowledgeable/ interest hiб its interest progect, but current time i work more on linux, but i can work and on win32 too. tell more about this project. Thanks Alexander A.Danilov al...@ap... ICQ: 112681102 |
From: Clayton H. <cla...@sp...> - 2003-09-22 13:08:03
|
Hi Gerald, (I have cc'd the list) No preference really, but you are doing awesome, thanks. The next couple of things I have on my plate are filesets and then tagging. I see filesets working like this: 1) Client passes in a list of files/ directories. 2) #cvs takes the list and converts them into folders/ entries in the following algorithm: a) If directory: i) Complete step b recursively. b) If file: i) Create folder object and fetch Root and Repository file information for that folder. ii) Fetch entries for each file name specified. c) Pass the compiled list to the Folders collection. d) Pass control to the specific command (i.e. update/ commit). I still need to look into what is needed for tagging. Clayton -----Original Message----- From: Gerald Evans [mailto:gn...@f2...]=20 Sent: September 22, 2003 3:12 AM To: Clayton Harbour Subject: Misc Unit Tests Clayton, I've only done unit tests for 2 of the files in Misc, partly due to your previous comments about wanting to remove the Misc directory, also=20 WorkingDirectory.cs appears to be in the middle of being changed (with=20 Obsolete attributes on many of the functions) and the remaining classes=20 being very small. Anyway I have attached tests for CvsRoot and PasswordScrambler. There is=20 also a patch for CvsRoot which fixes a minor problem where an invalid root=20 string could result in String.Substring throwing an=20 ArgumentOutOfRangeException rather than the ArgumentException that CvsRoot=20 is expected to throw. I've started looking at the Stream/FileHandler modules and hope to be able=20 to devise a way to test these. Please let me know if you have any preference to the order that I should be=20 implementing the tests. Gerald. |
From: Clayton H. <cla...@sp...> - 2003-09-22 12:51:51
|
Gerald, I have cc'd the #cvslib list. =20 Some very good questions and something I have thought about a (tiny) bit. Responses below. -----Original Message----- From: Gerald Evans [mailto:gn...@f2...]=20 Sent: September 22, 2003 4:51 AM To: Clayton Harbour Subject: Class visibility question Clayton, >1) Is there any documentation on the interface that sharpcvslib provides=20 >(or will provide) for developers wishing to make use of it in their >projects? C: Yes, there is some documentation (the API docs). There is not a lot there and it is a little mixed with the methods that we might want to be internal but it is a start. =20 >2) Is the intention to expose the minimum necessary to provide cvs support=20 >for other projects, or do we want to provide access to some/all of the=20 >internal 'helper' classes as well? C: The minimum necessary definitely. I see the Command, Misc (probably only pieces...and maybe with a better name) and Client namespace being the ones requiring he >3) As far as I can see, at the moment all classes are public so any user of=20 >the DLL has access to all of these classes. It users do start using the=20 >'helper' classes then this would make it more difficult for us to change=20 >them later on if we needed to, or would make it more difficult for users to=20 >upgrade to a later DLL. C: I agree, we should lock it down. >4) As the unit tests are in a separate DLL, does this mean that they would=20 >not be able to test the 'helper' classes if they were marked 'internal', or=20 >is there some way around it with multi-file assemblies? C: That is true, if the helpers are compiled separately from the main assembly then it would be impossible to test the internal helper methods. I have been thinking of a workaround for this which would be to build the test and source all into one assembly (the test assembly). I have attached the files to make this change and commented them with: // TODO: Change to internalize helpers with the type of change. If you like this I can commit what I have and then we can hash over the details of what needs to be internal and what we need to expose. Let me know what you think. Perhaps it is still a bit early to start worrying about the above, but was=20 just wondering if you had any specific intensions towards class visibility. Gerald. |
From: Clayton H. <cla...@sp...> - 2003-09-20 14:14:07
|
Ed, I will submit a bug report for the ssh problems you have with the cvs task. If you have additionally information (i.e. stack trace, etc.) could you please submit them to the #cvslib list? Thanks. Also if you are really stuck for cvs functionality you could wrap a cvs binary in an <exec />. Not a great solution (IMO) but it will get you by for now. Thanks for the feedback! Clayton -----Original Message----- From: Clayton Harbour=20 Sent: September 19, 2003 7:33 PM To: eei...@ro...; nan...@li... Cc: sha...@li... Subject: RE: [Nant-users] Version Labeling with NAnt Hi Ed, Sorry for the delayed reply. The bad news is that the support is not built in #cvslib yet. The good news is that it is third on the list of todos' (after checkout by sticky-tags and filesets support). If you would like to help out that would be great :-). Clayton -----Original Message----- From: Ed Eichman [mailto:eei...@ro...]=20 Sent: September 19, 2003 1:47 AM To: nan...@li... Subject: [Nant-users] Version Labeling with NAnt Hi Guys, How do I label a CVS version from an NAnt script? I checked google and the documentation for the answer, but did not find anything. I also checked the Ant documentation (just in case they could give me a hint), and did not see how to do this for CVS. Thanks, Ed Eichman Rocinante Software S.L. (www.rocinantesoftware.com) Cambrils, Spain ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-users mailing list Nan...@li... https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-users mailing list Nan...@li... https://lists.sourceforge.net/lists/listinfo/nant-users |
From: Clayton H. <cla...@sp...> - 2003-09-20 02:08:21
|
Hi Ed, Sorry for the delayed reply. The bad news is that the support is not built in #cvslib yet. The good news is that it is third on the list of todos' (after checkout by sticky-tags and filesets support). If you would like to help out that would be great :-). Clayton -----Original Message----- From: Ed Eichman [mailto:eei...@ro...]=20 Sent: September 19, 2003 1:47 AM To: nan...@li... Subject: [Nant-users] Version Labeling with NAnt Hi Guys, How do I label a CVS version from an NAnt script? I checked google and the documentation for the answer, but did not find anything. I also checked the Ant documentation (just in case they could give me a hint), and did not see how to do this for CVS. Thanks, Ed Eichman Rocinante Software S.L. (www.rocinantesoftware.com) Cambrils, Spain ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-users mailing list Nan...@li... https://lists.sourceforge.net/lists/listinfo/nant-users |
From: Clayton H. <cla...@sp...> - 2003-09-18 06:08:31
|
Hi Gerald, First of all, many thanks for the patches and the tests. I had a chance to checkout some of the TODO: statements. // TODO: Find out if there is any reason why the Factory class // does not have static methods No reason in particular. I guess I always have the idea in the back of my head that threading + static =3D=3D !good, but besides that paranoia there is no reason.=20 // TODO: need *nix style dir when testing on *nix Added an IsWindows, IsUnix switch using Path.DirectorySeperator as the switch. Not much testing but I think the idea is there. I also googled for some more ideas and got the following links which might be helpful: http://lists.ximian.com/archives/public/mono-list/2002-March/004521.html which links to: http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/cpref/= h tml/frlrfSystemIOPathClassVolumeSeparatorCharTopic.asp // TODO: check what format the date should come back in Assertion.Assert (entry.Date, entry.Date.Equals ("03 Jan 2003 04:07:36 -0000")); I agree with this one, based on the following: =20 http://www.elegosoft.com/cvs/cvsclient.html#SEC11 // TODO: Check if it makes any sense to test Revision, Date, etc. [In reference to directory information] Good question. I would say "no", I think in cvs folders are either there or they are there :-). I don't think the server passes down any date/ time information. Mostly just thoughts here, I could not find any documentation, but the tortoise files seem to confirm this. /// TODO: Check if this should really throw an exception. /// Cederqvist seems to imply that an invalid date is OK, /// and that the only thing that is important is whether=20 /// the timestamp of the actual file matches what's in=20 /// this field or not. I am not familiar with Cederqvist...I agree with you though, I do not think that the entry should be throwing an exception if it gets a "bad" date time format. If you don't think so either and we can pull it out. I have also created a parser to handle this ugly date string parsing. I will commit it so you can take a look (it will be in the hopefully not so ubiquitous Util namespace). Thanks again, I will post your code to the patches list. =20 Clayton -----Original Message----- From: Gerald Evans [mailto:gn...@f2...]=20 Sent: September 17, 2003 9:32 AM To: Clayton Harbour Subject: FileSystem unit tests Clayton, I've been looking at the unit tests for FileSystem. I've expanded the current tests for Root, Repository and Entry. There is a=20 patch file within FileSystem.zip for these. I have also added new files to test Factory, PathTranslator and Tag. These=20 files are included in the zip. I've left several 'TODO:'s in the code which I hope to be able to return to=20 when I have a better understanding of the system. The tests are pretty basic with very little testing of invalid arguments except for the cases where I have seen that the code explicitly checks for=20 invalid arguments. Please let me know if you would like the tests to be more exhaustive. Also attached is a small fix for PathTranslator. Currently a global replace is used to delete any occurence of the filename=20 within the entire path. If the filename did appear elsewhere in the path,=20 then the path would end up being incorrect. I was thinking of looking at Misc next together with some of the other=20 smaller directories. Gerald. |
From: Clayton H. <cla...@sp...> - 2003-09-15 15:29:58
|
Hi, First my name is Clayton Harbour, pleased to meet you. You can find most of the details of what I want to accomplish at http://sharpcvslib.sourceforge.net/wiki/index.php?page=3DProjectGoals. Basically #cvslib is going to replicate the functionality of cvsnt (http://cvsnt.org) and cvs (http://www.cvshome.org/) and provide a library for accessing these repositories for developers using the .net and mono (http://go-mono.com) platforms.=20 There are a number of internal things I would like to see implemented, such as a messaging system to output cvs requests/ responses (similar to tortoisecvs client logging). I would put a lot of priority on this sort of system, with support for filesets coming in just slightly ahead. =20 Given these two things and the information on the wiki if you could maybe tell me what area you were thinking about working on I could share some ideas about what I had in mind for it. =20 Thanks, Clayton -----Original Message----- From: srinivasa reddy telukutla [mailto:chi...@us...] Sent: September 15, 2003 8:15 AM To: dr...@us... Cc: chi...@us... Subject: RE: c# developer knowledgeable/ interested in cvs Hi Drakmar, I am interested in this project. Can you mail me the details so=20 that we can discuss about this. Thanks Srinivas. |
From: Clayton H. <cla...@sp...> - 2003-09-15 14:45:12
|
Hi, =20 I have finished adding support for sticky-tags (tagged revisions) and have committed the changes to cvs. I have also uploaded a zip file of the sources and binaries and added it to the following location: =20 http://sharpcvslib.sourceforge.net/nightly-build/ICSharpCode.SharpCvsLib -0.3.4.1-Revision-2003-09-15-bin.zip <http://sharpcvslib.sourceforge.net/nightly-build/ICSharpCode.SharpCvsLi b-0.3.4.1-Revision-2003-09-15-bin.zip>=20 http://sharpcvslib.sourceforge.net/nightly-build/ICSharpCode.SharpCvsLib -0.3.4.1-Revision-2003-09-15-src.zip <http://sharpcvslib.sourceforge.net/nightly-build/ICSharpCode.SharpCvsLi b-0.3.4.1-Revision-2003-09-15-src.zip>=20 =20 I have also added a list of files that were changed to the patches list. =20 =20 =20 Clayton |
From: Clayton H. <cla...@sp...> - 2003-09-13 20:37:29
|
Hi, =20 I am just sending a general note out to anyone who has subscribed to these lists. =20 If you are a new developer and/ or wish to submit a patch for review please send your patch to=20 sha...@li... <mailto:sha...@li...>=20 Also please include a test case with your patch. Note that the more information/ more complete your patch and test case the quicker the turn around time to get it committed to cvs. =20 If you are a user of #cvslib please send requests to: sha...@li... <mailto:sha...@li...>=20 Please include any error reports and (as accurate as you can recall) the steps needed to reproduce whatever block you have hit. =20 If you are a new developer and want to talk about design decisions or to inform other developers what sections you are working on/ impacting then please send correspondence to: sha...@li... <mailto:sha...@li...>=20 =20 =20 Thanks, =20 =20 Clayton Harbour |