The Subversion Version Control System Development

Alan Chandler | 27 Oct 2002 16:18

Re: networking repositories


On Sunday 27 October 2002 12:42 pm, Sebastien Cevey wrote:
> On Sun, Oct 27, 2002 at 01:40:40PM +0100, Sebastien Cevey wrote:
> > What about a single repos on your laptop, and when on your home
> > computer, you just commit to the desktop (since they seem to be in a
> > network) ? :)
>
> Oops I meant "you commit to the laptop", sorry for the confusion.

Nice idea - but not quite what I need.  The problem is that the laptop doesn't 
get backed up with quite the same degree of automation and frequency.

But I'll see if I can work with it for a while.

Would still like an answer to the orginal question - does dump/load 
combination work 

--

-- 
Alan Chandler
alan <at> chandlerfamily.org.uk

headers

cmpilato | 27 Oct 2002 20:30

Re: networking repositories

Alan Chandler <alan <at> chandlerfamily.org.uk> writes:

> On Sunday 27 October 2002 12:42 pm, Sebastien Cevey wrote:
> > On Sun, Oct 27, 2002 at 01:40:40PM +0100, Sebastien Cevey wrote:
> > > What about a single repos on your laptop, and when on your home
> > > computer, you just commit to the desktop (since they seem to be in a
> > > network) ? :)
> >
> > Oops I meant "you commit to the laptop", sorry for the confusion.
> 
> 
> Nice idea - but not quite what I need.  The problem is that the laptop doesn't 
> get backed up with quite the same degree of automation and frequency.
> 
> But I'll see if I can work with it for a while.
> 
> Would still like an answer to the orginal question - does dump/load 
> combination work 

Dump and load should work fine unless you are committing directly to
both repositories.  In that case, the workability of the dump/load
method will be strictly determined by the types of operations you do
on each repository, and how close you keep them in sync.

Of course, you could always use a more traditional method -- patches.

Have each repository setup with a post-commit hook that writes the
diffs for that commit out to a file (like the commit-email.pl that we
use on svn.collab.net).  Then, when you need to sync, you apply the
changes from, say, your laptop's repos to your desktop's working copy,

(Continue reading)

headers

Peter Davis | 27 Oct 2002 20:41

Re: networking repositories

On Sunday 27 October 2002 11:30, cmpilato <at> collab.net wrote:
> Have each repository setup with a post-commit hook that writes the
> diffs for that commit out to a file (like the commit-email.pl that we
> use on svn.collab.net).  Then, when you need to sync, you apply the
> changes from, say, your laptop's repos to your desktop's working copy,
> and commit them up (and vice-versa).

Is there a reason why the answer to distributed repositories is not as simple 
as this?  Could not Subversion (or somebody with some free time) provide an 
"official" tool to create, manage, and apply such patches?

--

-- 
Peter Davis

headers

cmpilato | 27 Oct 2002 23:30

Re: networking repositories

Peter Davis <peter <at> pdavis.cx> writes:

> On Sunday 27 October 2002 11:30, cmpilato <at> collab.net wrote:
> > Have each repository setup with a post-commit hook that writes the
> > diffs for that commit out to a file (like the commit-email.pl that we
> > use on svn.collab.net).  Then, when you need to sync, you apply the
> > changes from, say, your laptop's repos to your desktop's working copy,
> > and commit them up (and vice-versa).
> 
> Is there a reason why the answer to distributed repositories is not
> as simple as this?  Could not Subversion (or somebody with some free
> time) provide an "official" tool to create, manage, and apply such
> patches?

Shhh... Tom Lord will hear you. 

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

headers

Tom Lord | 27 Oct 2002 23:52

Re: networking repositories


       collab.net:
       > Just messin' with ya, Tom

Gee, thanks.

-t

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

headers

cmpilato | 27 Oct 2002 23:33

Re: networking repositories

cmpilato <at> collab.net writes:

> Peter Davis <peter <at> pdavis.cx> writes:
>
> > Is there a reason why the answer to distributed repositories is not
> > as simple as this?  Could not Subversion (or somebody with some free
> > time) provide an "official" tool to create, manage, and apply such
> > patches?
> 
> Shhh... Tom Lord will hear you. 

Tom Lord <lord <at> regexps.com> writes:

> Fine.  I'll bite.

Oops... too late.  (Just messin' with ya, Tom)

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

headers

Rafael Garcia-Suarez | 27 Oct 2002 21:29

Re: networking repositories

Peter Davis wrote:
> > Have each repository setup with a post-commit hook that writes the
> > diffs for that commit out to a file (like the commit-email.pl that we
> > use on svn.collab.net).  Then, when you need to sync, you apply the
> > changes from, say, your laptop's repos to your desktop's working copy,
> > and commit them up (and vice-versa).
> 
> Is there a reason why the answer to distributed repositories is not as simple 
> as this?  Could not Subversion (or somebody with some free time) provide an 
> "official" tool to create, manage, and apply such patches?

A quick list of problems with traditional patches (i.e. diff(1) output)
  * metadata (properties)
  * log messages
  * binary files
  * deletion of directories
  * addition of empty files
  * platform-dependent line-endings (ie. with svn:eol-style=native)
  * svn cp
Thus you'll need to add metadata in the output, and have the import
program correctly interpret this. (but it'd be great!)

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

headers

Florin Iucha | 28 Oct 2002 06:04

Re: networking repositories

On Sun, Oct 27, 2002 at 09:29:18PM +0100, Rafael Garcia-Suarez wrote:
> Peter Davis wrote:
> > > Have each repository setup with a post-commit hook that writes the
> > > diffs for that commit out to a file (like the commit-email.pl that we
> > > use on svn.collab.net).  Then, when you need to sync, you apply the
> > > changes from, say, your laptop's repos to your desktop's working copy,
> > > and commit them up (and vice-versa).
> > 
> > Is there a reason why the answer to distributed repositories is not as simple 
> > as this?  Could not Subversion (or somebody with some free time) provide an 
> > "official" tool to create, manage, and apply such patches?
> 
> A quick list of problems with traditional patches (i.e. diff(1) output)
>   * metadata (properties)
>   * log messages
>   * binary files
>   * deletion of directories
>   * addition of empty files
>   * platform-dependent line-endings (ie. with svn:eol-style=native)
>   * svn cp
> Thus you'll need to add metadata in the output, and have the import
> program correctly interpret this. (but it'd be great!)

Well, why not have the post-commit script do a dump(head-1, head) and
save it into a file? That should be rich enough.

It might need a bit of fudging on import, if you commit something 
before "resynching" but it should be doable.

Cheers,

(Continue reading)

headers

Florin Iucha | 28 Oct 2002 06:13

Re: networking repositories

On Sun, Oct 27, 2002 at 11:04:57PM -0600, Florin Iucha wrote:
> Well, why not have the post-commit script do a dump(head-1, head) and
> save it into a file? That should be rich enough.

Doh!

That contains the whole head... of course it is rich enough 8^)
It is just BIG!!!

Back to sleep before I say anything stupid,
florin

--

-- 

"If it's not broken, let's fix it till it is."

41A9 2BDE 8E11 F1C5 87A6  03EE 34B3 E075 3B90 DFE4

headers

Noel Yap | 28 Oct 2002 13:56

Re: networking repositories

--- Florin Iucha <florin <at> iucha.net> wrote:
> On Sun, Oct 27, 2002 at 11:04:57PM -0600, Florin
> Iucha wrote:
> > Well, why not have the post-commit script do a
> dump(head-1, head) and
> > save it into a file? That should be rich enough.
> 
> Doh!
> 
> That contains the whole head... of course it is rich
> enough 8^)
> It is just BIG!!!
> 
> Back to sleep before I say anything stupid,

It's not entirely stupid.  If there were a way to dump
just what was in the last commit, it might be possible
to combine it with Inside/Outside Lines
(http://www.enteract.com/~bradapp/acme/branching/branch-structs.html#InsideOutsideLines)
so that laptop development occurs on one branch while
desktop development occurs on another.  The two
branches can be merged, and the two repositories
synchronized (possibly by just creating a new copy),
periodically.

So now, the USD 64k question are, "Is there a way to
dump out just what was committed?" and "Is there a way
to load it back in lieu of other intermittent
commits?"

(Continue reading)

headers

Rafael Garcia-Suarez | 28 Oct 2002 14:01

Re: networking repositories

Noel Yap <yap_noel <at> yahoo.com> wrote:
> It's not entirely stupid.  If there were a way to dump
> just what was in the last commit,

Isn't this what "svnadmin dump --incremental" does ?

> it might be possible
> to combine it with Inside/Outside Lines
> (http://www.enteract.com/~bradapp/acme/branching/branch-structs.html#InsideOutsideLines)
> so that laptop development occurs on one branch while
> desktop development occurs on another.  The two
> branches can be merged, and the two repositories
> synchronized (possibly by just creating a new copy),
> periodically.

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

headers

Noel Yap | 28 Oct 2002 14:33

Re: networking repositories

--- Rafael Garcia-Suarez <rgarciasuarez <at> free.fr>
wrote:
> Noel Yap <yap_noel <at> yahoo.com> wrote:
> > It's not entirely stupid.  If there were a way to
> dump
> > just what was in the last commit,
> 
> Isn't this what "svnadmin dump --incremental" does ?

It sounds like it (I'm still a Subversion newbie so I
can't say for sure).

I think a naive way to achieve what the original
poster wants is:
0. Create laptop branch.
1. Create laptop copy of repo.
2. Laptop works on laptop branch.
3. Synch laptop repo with desktop repo by doing an
incremental dump.
4. Merge laptop branch into desktop branch.
5. Repeat from step 0 (this may be replaced with merge
desktop branch to laptop branch when merge history is
introduced).

I haven't tested the above so there may be small to
big tweaks needed.  The best place for optimization
may come from step 1 (rsync may be better).

HTH,
Noel

(Continue reading)

headers

Tom Lord | 27 Oct 2002 22:43

Re: networking repositories


Fine.  I'll bite.

   A quick list of problems with traditional patches (i.e. diff(1) output)
     * metadata (properties)
     * log messages
     * binary files
     * deletion of directories
     * addition of empty files
     * svn cp

arch takes care of all of those for you plus much, much more.  It has
been proposed and rejected to integrate these features of arch with
svn anytime soon.

     * platform-dependent line-endings (ie. with svn:eol-style=native)

I don't know much about this area, being rather focused on unix.
There is ongoing discussion on the arch-users mailing list about 
finalizing our changeset format and semantics, and if you have
an informed perspective on this issue, I encourage you to participate.

See: www.fifthvisiion.net/Arch to find the mailing list.

   Thus you'll need to add metadata in the output, and have the import
   program correctly interpret this. (but it'd be great!)

It is great.  A distributed system that handles these things well is a
joy to use.

(Continue reading)

headers

Scott Lamb | 28 Oct 2002 00:40

Re: networking repositories

Tom Lord wrote:
>    A quick list of problems with traditional patches (i.e. diff(1) output)
>      * metadata (properties)
>      * log messages
>      * binary files
>      * deletion of directories
>      * addition of empty files
>      * svn cp
> 
> arch takes care of all of those for you plus much, much more.  It has
> been proposed and rejected to integrate these features of arch with
> svn anytime soon.

"Proposed" is a vague word that ranges from "here's a patch to add this 
feature" to "I have this feature in arch. You don't have it in 
Subversion. You should add it in a similar way to how I did it in arch" 
and everything in between.

Likewise, "rejected" is vague. It could mean anything from "we don't 
feel that feature is valuable and bloats the code unnecessarily" to 
"we'd like to see that but can't expend effort on it".

I don't remember anyone arguing that the feature is not valuable, only 
that they couldn't take the time to implement it when they want 1.0 out 
the door. I don't remember anyone stopping you from working on it.

I'd love to see this feature, but I don't have enough time to spend on 
Subversion, enough familiarity with Subversion's innards (partially as a 
consequence of the first), or enough willpower to do basically anything 
of significance in plain C.

(Continue reading)

headers

Rafael Garcia-Suarez | 27 Oct 2002 22:54

Re: networking repositories

Tom Lord wrote:
>      * platform-dependent line-endings (ie. with svn:eol-style=native)
> 
> I don't know much about this area, being rather focused on unix.

That's quite simple, really. If diff(1) generates a patch between foo.orig
and foo, that have CRLF line endings, patch(1) won't apply it to a
copy of foo.orig that has LF line endings. Hence the diff output is non
portable where line endings may vary.

> There is ongoing discussion on the arch-users mailing list about 
> finalizing our changeset format and semantics, and if you have
> an informed perspective on this issue, I encourage you to participate.

Please don't suck me into yet another mailing list !-)

>    Thus you'll need to add metadata in the output, and have the import
>    program correctly interpret this. (but it'd be great!)
> 
> It is great.  A distributed system that handles these things well is a
> joy to use.

I can imagine this.

> It's instructive to look at the engineering practices going into the
> linux 2.6 effort to begin to understand why distributed revision
> control is critical, these days.  In reading the related materials,
> keep an eye out for phrases like "nicely broken out change/patch
> sets".

(Continue reading)

headers

Faried Nawaz | 27 Oct 2002 23:04

Re: networking repositories

Rafael Garcia-Suarez <rgarciasuarez <at> free.fr> writes:

  Off-topic question : besides Linux and Perl 5, are there out there significative
  open-source projects that use something more "recent" than CVS/RCS/SCCS (and
  that are not SCMs ?)

Does Perforce count?  The FreeBSD people use it for their tree.

Faried.
--

-- 
The Great GNU has arrived, infidels, behold his wrath !
"If a MOO runs on a port no one accesses, does it run?"

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

headers

Tom Lord | 27 Oct 2002 23:07

Re: networking repositories


       That's quite simple, really. If diff(1) generates a patch
       between foo.orig and foo, that have CRLF line endings, patch(1)
       won't apply it to a copy of foo.orig that has LF line
       endings. Hence the diff output is non portable where line
       endings may vary.

So, the question is, is there a coherent generalization of diff that
handles this cleanly, and should it be applied.

	Please don't suck me into yet another mailing list !-)

By all means -- leave one to join the other 

-t

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

headers

Zack Weinberg | 27 Oct 2002 23:50

Re: networking repositories

On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
> 
> 
>        That's quite simple, really. If diff(1) generates a patch
>        between foo.orig and foo, that have CRLF line endings, patch(1)
>        won't apply it to a copy of foo.orig that has LF line
>        endings. Hence the diff output is non portable where line
>        endings may vary.
> 
> 
> So, the question is, is there a coherent generalization of diff that
> handles this cleanly, and should it be applied.

It seems to me that patch(1) should just recognize and handle this
situation.  The correct behavior is obvious - accept CRLF and LF (and
CR) line endings, apply the transformation preserving the current
line-ending format of the target file.  Diffs do not work on binary
files anyway.

You could also consider this a special case of Karl (IIRC)'s
intelligent patch-merging algorithm.

zw

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

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

[arch-users] Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Tom Lord | 28 Oct 2002 02:22

Re: networking repositories


I think this belongs on arch-users.

-t

   Date: Sun, 27 Oct 2002 14:50:52 -0800
   Cc: rgarciasuarez <at> free.fr, peter <at> pdavis.cx, cmpilato <at> collab.net,
	   alan <at> chandlerfamily.org.uk, dev <at> subversion.tigris.org
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.4i
   From: Zack Weinberg <zack <at> codesourcery.com>
   X-UIDL: #4]"!-/5"!n83"!91-!!

   On Sun, Oct 27, 2002 at 02:07:33PM -0800, Tom Lord wrote:
   > 
   > 
   >        That's quite simple, really. If diff(1) generates a patch
   >        between foo.orig and foo, that have CRLF line endings, patch(1)
   >        won't apply it to a copy of foo.orig that has LF line
   >        endings. Hence the diff output is non portable where line
   >        endings may vary.
   > 
   > 
   > So, the question is, is there a coherent generalization of diff that
   > handles this cleanly, and should it be applied.

   It seems to me that patch(1) should just recognize and handle this
   situation.  The correct behavior is obvious - accept CRLF and LF (and
   CR) line endings, apply the transformation preserving the current

(Continue reading)

headers

Faried Nawaz | 27 Oct 2002 16:59

Re: networking repositories

I, too, have thought about this problem.  In my case, I usually work
offline.  I can keep my repo here, at home.  The problem is, I want to
give read-only access to the repo to other people (I have webhosting at
a friend's place where I can run apache2+mod_svn).

I think I'll proably end up rsyncing the repository from my box to
the web server every so often.  I'll

- shut down apache2
- rsync from my home box over
- start apache2

since I don't think (know) it's safe to rsync when clients might be
accessing stuff.

Faried.
--

-- 
The Great GNU has arrived, infidels, behold his wrath !
"If a MOO runs on a port no one accesses, does it run?"

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