Message-ID: <418E2F77.4030400@johnmeinel.com>
Date: Sun, 07 Nov 2004 08:21:43 -0600
From: John Meinel <tla@johnmeinel.com>
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626)
MIME-Version: 1.0
To: andreif@mail.dntis.ro
Subject: Re: [Gnu-arch-users] tla changes --diffs question
References: <1099820928.418def80e0698@webmail.dntis.ro>
In-Reply-To: <1099820928.418def80e0698@webmail.dntis.ro>
Cc: gnu-arch-users@gnu.org
Precedence: list
Content-Type: multipart/mixed; boundary="===============0505965808=="
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 4507
Lines: 120
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0505965808==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig58489DFC092F07DDFEB8117F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig58489DFC092F07DDFEB8117F
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

andreif@mail.dntis.ro wrote:
> John A Meinel [tla@johnmeinel.com] wrote:
> 
>>Files are supposed to always be "binary". They aren't 
>>supposed to be modified as a part of commit. (Whatever 
>>you commit should be exactly what you get.)
>>
>>That is why it is actually a bug in tla-cygwin-1.2.1. 
>>Just realize that while *you* might be able to check 
>>out your source tree, it is fairly likely that someone 
>>with a main-line tla will not be able to, as it is 
>>probably already corrupted. To explain simply, 1.2.1 
>>ignores line endings and generates changesets which 
>>conflict if you pay attention to them. Since all other 
>>tla's pay attention to line ending, you get into 
>>trouble.
> 
> 
> I understand, though for a project that has coders 
> working on Windows/Linux/Mac with different ways of 
> writing endlines it makes sense to change all endline 
> markers to LF inside the archive. It looks bad that it 
> changed from 1.2.1 and it will allow 1.2 to commit 
> which might include some unusual line endings in the 
> archive, wish that if 1.2.1 when took that road it 
> would change the repository format in some way not to 
> allow 1.2 to commit.
> 
> But this is not so bad from my point of view, what I 
> find unpardonable is that when I commit a file to 
> archive then make some changes and do a tla changes --
> diff it will not do the diff on the new file with the 
> CRLF changed to LF.
> 
> For the moment I will stick to 1.2.1 for the project 
> that I've already put into 1.2.1 as I am the only 
> developer on it - and use 1.2 for all other projects. I 
> am a bit disappointed, I switched from CVS to arch as 
> CVS has problems in the rename area and I heard arch so 
> praised - but looks like arch has some consistency 
> problems :(
> 
> Best Regards,
> Andrei
> 

Well, I would say arch does a lot of things right. But the windows ports 
are not a priority for the primary developers. Supporting windows is a 
secondary attempt, so it is not nearly as polished as arch proper.

There have been some discussions about how to do something that would 
cover what you want, and even a little bit more. So right now we all 
worry about LF, CRLF, CR. But also when you get into international 
stuff, you have to start worrying about file encoding. Is it UTF-8, 
Latin-1, ISO-8859-1, or ISO-8859-15, etc.

The idea would be that you could define your archive as a particular 
encoding type, and then on checkout/checkin it would be trans-coded to 
that type.

Obviously, the archive type would have to be some sort of superset of 
the local type, (like one of the Unicode types.) but it should be possible.

There is some hesitancy in this, as quite a few people like that arch 
*doesn't* modify their files. And that in this scenario, anyone who 
wants to work on the tree also needs the trans-coding tools, etc.

I also wonder if something like this can be layered on top of arch. For 
instance, with a precommit hook, you can change all line endings to LF. 
I don't think a pre-checkout hook exists yet, but I think you could tie 
into there and make sure before a patch is applied, the line endings are 
correct.

John
=:->

--------------enig58489DFC092F07DDFEB8117F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBji95JdeBCYSNAAMRAprgAJ9lRpA5T/UsRrc9P6c2KEUdbVQ6CwCfZeQn
4+SFxq7dmx39SA15cBDwL7g=
=DA1r
-----END PGP SIGNATURE-----

--------------enig58489DFC092F07DDFEB8117F--


--===============0505965808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
--===============0505965808==--