[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Cygwin Install, Misc. Documentation and Install Comments

From: Smith, Eric V. <ericsmith_at_windsor.com>
Date: 2003-01-09 00:20:01 CET

> I've been using subversion client (0.15) in combination with
> cygwin with no
> problems at all. Windows accepts forward slashed in filenames
> just as well
> as backslashes (it's cmd.exe which gets confused about it),
> so as long as
> you use relative path-names and avoid cygwin symlinks you
> have no problems.

I think the problem the original poster was talking about was having svn
understand the cygwin "paths", created with "mount". For example, on my
box doing an "ls /tmp" shows the contents of c:/opt/cygwin/tmp, because
c:/opt/cygwin is mounted as /. It would be nice if svn were buildable
as a cygwin app, so it could also understand cygwin's mount table.

> -----Original Message-----
> From: Andrew [mailto:asha@onezero.org]
> Sent: maandag 6 januari 2003 21:40
> To: dev@subversion.tigris.org
> Subject: Cygwin Install, Misc. Documentation and Install Comments
> Hello..
> Subversion looks nice. I used CVS for 4 years and would like to use
> Subversion in a new project that I am starting now. I'm itching to
> go -- getting a revision control system in place is the project's top
> priority.
> The project is being developed mostly in the Cygwin environment. So,
> I want to use a version of Subversion that knows about
> Cygwin/Unix-like
> path names. It would be awful to have to continually translate paths
> between Unix-style slashes and Windows-style backslashes. Using CVS
> would probably be better than that.
> It is possible to invoke a for-Windows Subversion binary from Cygwin,
> but that binary won't know about Cygwin path names. It seems that in
> order to get Subversion to know about Cygwin-style path names, it's
> necessary to use a version of Subversion that was built under Cygwin,
> or at least specifically to handle CYgwin-style paths in some way.
> So, a few weeks ago I tried building and installing Subversion under
> Cygwin, using a recent version from the Subversion source repository
> at tigris. (I do not recall which version.) I ran into one or more
> problems running ./configure. I spent several hours debugging the
> script and looking for information at Google, but eventually gave up.
> Unfortunately I have since deleted the directory that contained the
> build and install attmept, so I can't provide much more information.
> I was wondering if anyone had installed Subversion on Cygwin recently.
> At the time I tried to get Subversion to build under Cygwin,
> it looked like
> the last semi-official install attempt was in February (maybe February
> 28 -- I am writing from memory). If nobody has tried this recently,
> could a Subversion build/install guru take a look? February was a
> long time ago -- it would be nice for those of us that just
> want to use
> Subversion to have it work on Cygwin right out of the box.
> In return for help with this vague "it won't go on Cygwin" report,
> I am contributing some notes that I made a few weeks ago about ways
> that the Subversion documentation and install process might
> be improved.
> Even though the notes are somewhat raw, I think they're
> comprehensible;
> if something is unclear, let me know and I'll try to clarify.
> I've subscribed to dev@subversion.tigris.org to be able to
> see responses.
> I'll probably unsubscribe after a few days, as my interest is
> in getting
> Subversion installed on Cygwin, and not in the high traffic
> on the list.
> Thanks in advance for any help.
> - Andrew
> Here are the notes about the Subversion book.
> add date to the title page
> svn resolve
> how about having it warn you if there are new conflict markers
> in the file:
> $ svn resolve sandwich
> Not resolved; sandwich contains new conflict markers
> You can use "svn resolve -f" to force resolution.
> svn ignore
> bias towards certain files; default should be to ignore nothing
> "Note that<svn resolve> --> "Note that <svn resolve>"
> "svn ci --file logmsg" --> "$ svn commit --file logmsg"
> page 27: COMMITTED overwrites its table entry
> ("The last revision in which ...")
> I think this happens in an earlier table also; I don't remember where.
> How about using lower case letters for head, base, committed,
> and prev?
> I didn't see capital letters anywhere else in svn so far.
> page 28 (description of svn import) -- refers to "svnadmin create",
> which has not yet been described in the document at this point.
> Explain the name of "svn cat" -- it will make no sense to
> non-UNIX users.
> What do the "-500" items mean in the examples with dates and times?
> In "svn list" output, instead of showing a _ for every item
> that doesn't have a property, how about just showing nothing
> there (a space)?
> Also, "The columns tell you if a file has ..." -->
> "The columns tell you if a file or directory has ..."
> It would be nice for the guided tour to give a quick introduction to
> creating repositories.
> What I've read so far of the documentation is quite good.
> I desire quick start documentation -- just a few pages (5 at
> most) about
> how to create a repository, check out a file, and check in a
> file, with
> pointers at the end of the quick start documentation to the
> documentation
> for the next-most-common tasks.
> Add an index to the document.
> About what are currently called "properties" in Subversion parlance:
> I don't know if "property" is a standard term beyond its meaning in
> C#, but from my point of view it's a bit unpleasant to have "property"
> mean one thing in C# and another in Subversion. I wonder if the
> Subversion world would be served best by calling this thing
> "attribute"
> rather than "property" as it's currently called.
> Regularly building pre-built binaries for Cygwin and putting
> them and the
> necessary brief install documentation up at tigris might significantly
> expand the Subversion user base. For example I bet making a Cygwin
> binary and install documentation update every six months
> would be fine in
> most cases. Most people are going to be interested in using
> Subversion,
> I think, not in the intricacies of building and installing
> it. I might
> be wrong about how other people feel but at there is a data point here
> from one potential Subversion user that would like to use it
> rather than
> debug builds and installs.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 9 00:20:35 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.