".svn directories now hidden on Windows" ?

[Daniel Gehriger <ge...@linkcad.com>]

I just installed 0.24.1 because according to the CHANGELOG, it hides the
.svn directories. However, a this doesn't seem to be the case. Am I missing
something ?

- Daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: workaround for $WorkingRevision$ ?

[Bill Comisky <bc...@pobox.com>]

On Wed, 18 Jun 2003, Ben Collins-Sussman wrote:

> Bill Comisky <bc...@pobox.com> writes:
> 
> > Suffice to say I'd like to have my code "know" somehow what the HEAD 
> > revision number was when the wc was last updated/checked out/exported.
> > 
> > Am I making sense yet? :)
> 
> Sure.  You want your code to assume that the whole working copy is at
> a single working revision, and to push that revision into generated
> data.
> 
> So maybe your code can simply run 'svnversion' on the wc?   That's the
> reason Philip wrote svnversion.
> 

Cool, I didn't know about svnversion.  For exported code, I'll just make 
sure to make a tag first & then parse $HeadURL$.

thanks,
bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: workaround for $WorkingRevision$ ?

[Ben Collins-Sussman <su...@collab.net>]

Bill Comisky <bc...@pobox.com> writes:

> Suffice to say I'd like to have my code "know" somehow what the HEAD 
> revision number was when the wc was last updated/checked out/exported.
> 
> Am I making sense yet? :)

Sure.  You want your code to assume that the whole working copy is at
a single working revision, and to push that revision into generated
data.

So maybe your code can simply run 'svnversion' on the wc?   That's the
reason Philip wrote svnversion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: workaround for $WorkingRevision$ ?

[Bill Comisky <bc...@pobox.com>]

On Wed, 18 Jun 2003, Ben Collins-Sussman wrote:

> Bill Comisky <bc...@pobox.com> writes:
> 
> > I have a repository of source code for an interpreted (not-compiled)
> > language, in this case Matlab m-files.  It's very useful for me to be able
> > to record the "working revision" in output files generated by this code.  
> > For example if an incompatiblity in the output file format is introduced,
> > I can determine what revision it was created with and backtrack.
> > 
> > I've been reading the archives about a $WorkingRevision$ keyword (which
> > would be perfect for what I want) [...]
> 
> Let's back up a step.  I don't understand why $LastChangedRevision$ is
> insufficient for solving your problem.
> 
> I mean, if one generated file claims to have been produced by "working
> revision 170", and another one by "working revision 171", does that
> *mean* anything?  Most likely, revs 170 and 171 of the m-file are
> completely identical.
> 
> $LastChangedRevision$ is the true "version" of the file.  Isn't that
> what you care about?

It's not a particular file I'm interested in.  It's what the HEAD revision
number was when the working copy was last updated (or checked out/exported
as appropriate).  Maybe I confused the issue by mentioning my "output
file" example.  Those aren't versioned files, but IO files generated by
users running the code.  I'd like to record the revision number of the 
code that generates the file, in that file AT RUNTIME.  Anyone using a 
mixed-revision wc is out of luck.  

Suffice to say I'd like to have my code "know" somehow what the HEAD 
revision number was when the wc was last updated/checked out/exported.

Am I making sense yet? :)

bill

-- 
Bill Comisky
bcomisky@pobox.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: workaround for $WorkingRevision$ ?

[Ben Collins-Sussman <su...@collab.net>]

Bill Comisky <bc...@pobox.com> writes:

> I have a repository of source code for an interpreted (not-compiled)
> language, in this case Matlab m-files.  It's very useful for me to be able
> to record the "working revision" in output files generated by this code.  
> For example if an incompatiblity in the output file format is introduced,
> I can determine what revision it was created with and backtrack.
> 
> I've been reading the archives about a $WorkingRevision$ keyword (which
> would be perfect for what I want) [...]

Let's back up a step.  I don't understand why $LastChangedRevision$ is
insufficient for solving your problem.

I mean, if one generated file claims to have been produced by "working
revision 170", and another one by "working revision 171", does that
*mean* anything?  Most likely, revs 170 and 171 of the m-file are
completely identical.

$LastChangedRevision$ is the true "version" of the file.  Isn't that
what you care about?




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

workaround for $WorkingRevision$ ?

[Bill Comisky <bc...@pobox.com>]

I have a repository of source code for an interpreted (not-compiled)
language, in this case Matlab m-files.  It's very useful for me to be able
to record the "working revision" in output files generated by this code.  
For example if an incompatiblity in the output file format is introduced,
I can determine what revision it was created with and backtrack.

I've been reading the archives about a $WorkingRevision$ keyword (which
would be perfect for what I want), and the concerns about mixed-revisions
and work arounds by parsing "svn info" at build time.  But since I don't
have to compile, I can't use a Makefile as a good way to be sure the
$WorkingRevision$ gets updated in some file.

I was hoping someone had a clever idea of a workaround for my scenario.  
I've thought of:

- Using tags extensively and parsing $HeadURL$.  The problem here is that
this is needed in a development environment, tagging every commit doesn't
seem realistic.

- Just making everyone run another script to parse "svn info" and dump the
WorkingRevision after every "svn update", "svn checkout", "svn export",
other?  This relies on people remembering an extra step, and is bound to
fail sometimes.  Maybe have special commands that do everything in one
step? But I don't want to obfuscate the svn command line interface.

- Kludging some server side (pre,post?)-commit script to automatically
update a file containing the WorkingRevision.  Not sure exactly how I
would do this.  An update & commit of my WorkingRevision file?  So I'd
advance 2 revision numbers on every commit?  And I'd have to make sure not
to get stuck in a infinite recursive cycle.  Yuck.  The only thing nice
here is that I'd have the WorkingRevision on update, checkout, export.
  
Hopefully I overlooked something nice and simple, and someone will fill me
in.

thanks,
bill

-- 
Bill Comisky
bcomisky@pobox.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ".svn directories now hidden on Windows" ?

[cm...@collab.net]

Michael Price <mi...@computer.org> writes:

> So how should I handle this? Should I include HEAD versions of
> apr/apr-util in the next tarball or explain that we don't really have
> this "feature" until the next apache release?

The latter, please.  We really want to stick with released versions of
our dependent libraries as much as possible.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: ".svn directories now hidden on Windows" ?

[Michael Price <mi...@computer.org>]

--- Sander Striker <st...@apache.org> wrote:
> > From: Michael Price [mailto:michael.price@computer.org]
> > The included versions of apr and apr-util are the APACHE_2_0_46 tag
> > from the cvs repo. Someone in the know should check and see if that
> > version has the necessary bits.
> 
> Being the one that laid that tag I can tell you it _doesn't_ include
> that functionality.

So how should I handle this? Should I include HEAD versions of
apr/apr-util in the next tarball or explain that we don't really have
this "feature" until the next apache release?

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: ".svn directories now hidden on Windows" ?

[Sander Striker <st...@apache.org>]

> From: Michael Price [mailto:michael.price@computer.org]
> Sent: Wednesday, June 18, 2003 7:18 PM

> --- cmpilato@collab.net wrote:
> > "Daniel Gehriger" <ge...@linkcad.com> writes:
> > > I just installed 0.24.1 because according to the CHANGELOG, it
> > > hides the .svn directories. However, a this doesn't seem to be
> > > the case. Am I missing something ?
> > 
> > Do you have your Explorer set up to display hidden files?  If so,
> > there's nothing we can do about that.
> 
> Another possibility is that the bundled version of apr/apr-util doesn't
> include the necessary functionality. I don't have a Windows box so I
> couldn't test that feature.
> 
> The included versions of apr and apr-util are the APACHE_2_0_46 tag
> from the cvs repo. Someone in the know should check and see if that
> version has the necessary bits.

Being the one that laid that tag I can tell you it _doesn't_ include
that functionality.


Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ".svn directories now hidden on Windows" ?

[Michael Price <mi...@computer.org>]

--- cmpilato@collab.net wrote:
> "Daniel Gehriger" <ge...@linkcad.com> writes:
> > I just installed 0.24.1 because according to the CHANGELOG, it
> > hides the .svn directories. However, a this doesn't seem to be
> > the case. Am I missing something ?
> 
> Do you have your Explorer set up to display hidden files?  If so,
> there's nothing we can do about that.

Another possibility is that the bundled version of apr/apr-util doesn't
include the necessary functionality. I don't have a Windows box so I
couldn't test that feature.

The included versions of apr and apr-util are the APACHE_2_0_46 tag
from the cvs repo. Someone in the know should check and see if that
version has the necessary bits.

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ".svn directories now hidden on Windows" ?

[cm...@collab.net]

"Daniel Gehriger" <ge...@linkcad.com> writes:

> I just installed 0.24.1 because according to the CHANGELOG, it hides the
> .svn directories. However, a this doesn't seem to be the case. Am I missing
> something ?

Do you have your Explorer set up to display hidden files?  If so,
there's nothing we can do about that.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org